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EXECUTIVE  SUMMARY 


The  Office  of  Naval  Research  (ONR)  has  established  an  Innovative  Naval  Prototype  (INP)  program 
—  Integrated  Topside  (InTop)  —  to  address  the  current  condition  in  which  U.S.  Navy  surface  combatants 
are  increasingly  employing  large  numbers  of  federated  radio  frequency  (RF)  apertures  to  perform 
electronic  warfare,  communication,  and  radar  functions.  Each  of  these  functions  (and  hence  individual 
systems)  historically  has  its  own  aperture,  electronics,  operator,  and  logistics/maintenance  tail.  This 
classic  stand-alone  RF  systems  approach  results  in  electromagnetic  interference/compatibility 
(EMI/EMC)  problems  that  degrade  system  performance  and  increase  life-cycle  cost  for  the  combatant. 
Additionally,  ship  RF  signature  and  radar  cross  section  are  difficult  to  reduce  when  restricted  to  stand¬ 
alone  RF  aperture/antenna  approaches.  Most  importantly,  new  communications  and  sensor  requirements 
are  increasing  space,  weight,  and  power  demands  on  the  topsides  and  masts  of  new  platforms,  which 
consequently  leads  to  larger  ships  requiring  increased  generating  capacity  and  incurring  significantly 
higher  cost. 

ONR’s  vision  for  InTop  is  to  provide  Navy  platforms  with  adaptable  RF  capabilities  at  reduced  cost, 
manning,  and  hull  size  by  developing  integrated  sensor  and  communication  solutions  that  are  affordable, 
open,  modular,  and  scalable;  seamlessly  incoiporated  into  new  platform  designs  and  structures;  and 
architected  to  efficiently  grow  with  future  operational  requirements.  InTop  focuses  primarily  on  new 
construction  and  Ship  Life  Extension  Programs,  but,  where  appropriate,  will  also  integrate  with  or  replace 
existing  systems  on  legacy  platforms. 

Initial  tasks  assigned  under  the  InTop  program  were  for  the  Navy  to  study  ship  RF  systems 
requirements,  and  jointly  with  industry  to  investigate  the  critical  aspects  of  open  architecture  (OA)  within 
an  InTop1  system  of  systems  which  will  be  developed  in  a  spiral  approach  over  a  period  of  several  years. 
In  general  this  report  addresses  the  potential  benefits  and  challenges  of  realizing  the  vision  of  RF  systems 
based  on  OA.  In  particular,  it  provides  guidance  and  a  starting  point  for  InTop  and  other  future  efforts  on 
an  appropriate  level  of  “granularity”  in  dividing  an  open  RF  system  architecture  into  a  reasonable  set  of 
constituent  hardware  and  software  components. 

Open  architecture  is  the  confluence  of  business  and  technical  practices  yielding  modular, 
interoperable  systems  that  adhere  to  open  standards  with  published  interfaces.  The  critical  features  of  OA 
as  addressed  in  this  study  include  the  following: 

•  Modular  system  architectures  consisting  of  well-defined  hardware  and  software  components  with 
standard  and/or  government- owned  hardware  and  software  interfaces.  Hardware  components 


1  The  term  “InTop”  refers  to  the  overarching  InTop  System  of  Systems;  references  to  “InTop  systems”  refer  to 
individual  systems  that  are  considered  to  be  one  (or  more)  of  the  overarching  InTop  System  of  Systems. 
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include  Ship  Replaceable  Units  (SRUs)  and  Shop  Replaceable/Repairable  Assemblies  (SRAs); 
software  components  include  Computer  Software  Configuration  Items  (CSCIs).2 

•  The  ability  to  develop  new  modular  components/building  blocks  that  can  be  adapted  to  interface 
with  or  replace  units  in  previously  developed  systems.  This  feature  allows  developers  to: 

•  improve  performance  of  the  base  system  by  adding  or  replacing  components  with 
enhanced  capability  from  multiple  sources; 

•  extend  the  life  of  the  base  system  by  replacing  unsupported  units  with  new,  more  reliable 
and  repairable  units;  and 

•  spirally  integrate  new  InTop  systems  into  previously  developed  InTop  suites  of  systems 
and  associated  resource  allocation  management  software. 

•  The  ability  to  scale  InTop  systems  to  accommodate  variable  platform  size,  system,  and 
operational  performance  requirements. 

A  common  misconception  of  OA  is  that  it  is  a  process  to  allow  the  Navy  during  initial  system 
development  to  compete  and  procure  individual  SRUs/SRAs  and  CSCIs  that  may  then  be  integrated  as  a 
system  in  a  manner  similar  to  buying  individual  commercial  off-the-shelf  computer  components  and  tying 
them  together  on  a  common  backplane.  While  this  might  be  possible  in  the  future  if  Navy  acquisition 
offices  elect  to  take  on  the  responsibility  of  the  system  integrator  and  ultimate  system  performance,  we 
did  not  consider  this  to  be  the  typical  acquisition  strategy  for  the  initial  development  of  new  systems.  The 
process  during  the  initial  development  must  focus  instead  on  identifying  the  modular  building  blocks  and 
their  interfaces  so  that  the  Navy  may  in  the  future  compete,  procure,  and  integrate  individual  hardware 
and  software  components  (or  previously  developed  InTop  systems)  during  subsequent  iterations  for 
improvements  in  both  performance  and/or  life-cycle  cost. 

For  this  study,  four  joint  Navy/industry  teams  were  established  based  on  the  broad  architectural 
subsystems  of  a  general  RF  system  for  Navy  platforms: 

•  the  Receive/Transmit  Aperture  Subsystem  Study  Group; 

•  the  Radio  Frequency/Intermediate  Frequency  (RF/IF)  Subsystem  Study  Group; 

•  the  Digital  Signal  Processor  (DSP)  and  Data  Processing/Software  (DP/SW)  Subsystems 

Study  Group;  and 

•  the  Resource  Allocation  Manager/Software/Combat  System  (RAM/SW/CS)  Subsystems 

Study  Group. 

A  fifth  team,  the  Integrated  Topside  Oversight  Board  (ITOB),  addressed  system  engineering 
issues  and  provided  technical  and  management  oversight  to  the  four  functional  teams. 

These  teams  were  tasked  to  consider  how  these  four  generic  architecture  blocks  might  be  further 
divided  into  modular  hardware  and/or  software  components  suitable  for  an  open  architecture.  An  OA 
component  may  generally  be  considered  to  be  an  SRU/SRA  or  CSCI  that  performs  a  specific  function  to 
accomplish  a  well-defined  requirement,  and  has  non-proprietary/open  interfaces  (preferably  to  an  industry 
standard);  the  internal  design  of  an  OA  component,  however,  may  be  proprietary  to  one  or  more 


2  An  open  architecture  “component”  is  one  of  the  parts  that  make  up  a  system.  A  component  may  be  hardware  or 
software  and  may  be  subdivided  into  other  components;  cf.  Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
Std  610.12-1990.  In  this  study,  we  considered  SRUs  and  CSCIs  to  be  primary  components  (i.e.,  architecture 
“building  blocks”)  and  SRAs  to  be  secondary  components,  as  applicable,  within  SRUs. 
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providers.  The  teams  then  analyzed  the  resulting  modular  architectures  as  they  related  to  communications 
and  sensor  systems. 

The  conduct  of  this  Open  Architecture  Study  and  the  development  of  notional  InTop  architectures 
and  interfaces  by  joint  teams  of  Navy  and  industry  program  and  technical  personnel  provided  a  significant 
benefit  to  the  InTop  program.  It  both  reinforced  among  all  participants  the  reasons  and  requirements  for  a 
modular  open  systems  approach  to  the  development  of  an  integrated  system  of  systems,  and  concentrated 
attention  on  how  InTop  and  its  subsidiary  systems  might  best  be  architected  to  benefit  from  the  OA 
concept. 

The  primary  technical  benefit  of  the  OA  study  was  to  identify  and  define  functional/generic 
components  and  their  related  interfaces  that  can  be  expected  to  be  non-proprietary  and  relevant  to  most 
InTop  systems.  Subsequent  InTop  efforts  will  focus  on  architectures  based  on  these  component  building 
blocks,  and  develop  open  interfaces  as  the  core  of  a  modular  open  systems  approach. 

The  primary  program  benefit  of  this  OA  study  was  a  mutual  recognition  by  InTop  participants  of 
recent  Navy  difficulties  with  updating  and  integrating  both  legacy  and  new  systems  encumbered  with 
proprietary  hardware  and  software.  Future  InTop  development  must,  therefore,  incoiporate  the  principles 
of  open  architecture  to  effectively  adapt  to  existing  communications  and  sensor  systems,  new  platform 
operational  and  design  requirements,  and  associated  new  and  legacy  combat  control  systems. 

The  primary  business  impact  on  industry  of  adopting  an  OA  approach  involves  intellectual  property 
(IP)  and  broader  open  competition.  While  it  is  recommended  that  new  OA  systems  be  developed, 
integrated,  and  delivered  by  a  single  prime  contractor  responsible  for  all  aspects  of  cost,  schedule,  and 
performance,  IP  should  be  limited  to  well-defined  components  —  SRUs/SRAs  and  CSCIs.  In  turn, 
however,  the  competition  for  future  enhancements  should  be  open  to  all  and  not  restricted  to  the  original 
prime  contractor.  This  widening  and  leveling  of  the  “playing  field”  increases  new  business  opportunities 
for  all  without  restricting  companies  to  their  past  legacy  systems.  Additionally,  OA  increases  the  prime 
contractor’s  make-buy  opportunities  and  its  ability  to  deliver  a  better  product  at  lower  cost  by  providing 
greater  incentive  for  outside/niche  development  of  OA  components.  The  OA  modular  approach  also 
increases  the  domestic  and  foreign  market  by  providing  additional  flexibility  to  support  new  platforms 
with  varying  configurations  and  operational  requirements. 

In  summary,  there  was  general  consensus  on  both  the  benefits  and  concerns  of  OA-based  system 
development.  Potential  business/acquisition  benefits  include 

•  enabling  increased  industry  competition  and/or  collaboration; 

•  leveraging  commercial  investment  and  commercial  innovation; 

•  realizing  cost  advantages  of  larger  supplier  and  customer  bases; 

•  enhancing  access  to  cutting-edge  technologies  and  products  from  multiple  suppliers; 

•  mitigating  the  risks  associated  with  technology  obsolescence; 

•  mitigating  the  risk  of  a  single  source  of  supply  over  the  life  of  a  system; 

•  enhancing  commonality  and  reuse  of  components  among  systems;  and 

•  enhancing  life-cycle  supportability,  reducing  maintenance  costs. 

Potential  benefits  to  operational  performance  for  OA-based  topside  systems  include 

•  the  ability  to  adapt  to  evolving  requirements  and  threats; 

•  accelerating  the  transition  from  science  and  technology  into  acquisition  and  deployment  (make 
technology  refresh  an  asset,  not  a  liability); 

•  ensuring  that  the  system  will  be  interoperable  with  all  the  systems  which  it  must  interface, 
without  major  modification  of  existing  components;  and 

•  improving  the  extensibility  for  meeting  new  requirements  and  for  introducing  new  capabilities. 
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Along  with  these  benefits,  however,  come  challenges,  risks,  and  implications  that  may  affect  both 
the  Government  and  industry  on  several  fronts.  These  include  the  following: 

•  “Open”  information  —  interfaces  and  specifications  —  developed  by  the  prime  contractor  must 
be  confirmed  to  be  sufficient  and  accurate  before  initiating  component  procurement  from  an 
alternate  source  and  subsequent  integration  into  a  fielded  system. 

•  The  price  for  lower  total  life-cycle  costs  could  be  higher  initial  acquisition  cost. 

•  Commercial  product  lifetimes  are  generally  much  shorter  than  that  of  the  weapon  system, 
creating  challenges  to  logistical  support  functions. 

•  To  maintain  a  healthy  supplier  base,  the  contract  community  (large  defense  contractors, 
commercial  product  houses,  and  niche  system  element  developers)  must  see  a  sustainable,  long¬ 
term  business  case.  The  Navy  must  provide  protection  of  contractor  intellectual  property  within 
the  SRUs,  even  as  it  demands  compliance  to  open,  non-proprietary  interfaces. 

•  Standards  selection  can  be  risky  and  problematic.  It  will  require  that  the  Government  have  more 
knowledge  of  the  current  state  of  the  art  and  the  marketplace. 

•  Interface  standards  evolve  with  time.  It  is  difficult  to  project  the  extent  to  which  a  given  standard 
will  endure.  It  is  also  challenging  to  determine  when  to  change  from  one  standard  to  the  next. 

•  Standards-based  architectures  tend  to  change  the  focus  of  systems  engineering  from  design  to 
integration.  The  challenge  is  to  achieve  performance  requirements  without  detailed  control  over 
the  component  design  specification. 


The  Navy  needs  to  weigh  these  benefits  and  concerns  to  prove  to  itself  that  implementing  its  concept 
for  a  multifunction  RF  integrated  topside  incorporating  OA  principles  is  cost-effective  and  mission- 
compliant  over  the  long  term.  To  do  this  will  require  accurate  and  credible  cost  models,  a  sustainable 
technology  and  engineering  base,  and  a  willingness  by  the  Navy  to  alter  its  own  cultural  and  acquisition 
processes. 
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INTEGRATED  TOPSIDE  (INTOP) 
JOINT  NAVY-INDUSTRY 
OPEN  ARCHITECTURE  STUDY 


1.  INTRODUCTION 

Integrated  Topside  (InTop)  is  an  Innovative  Naval  Prototype  (INP)  program  established  by  the 
Office  of  Naval  Research  (ONR)  to  develop  an  integrated,  multifunctional  system  of  electronic  warfare 
(EW),  information  operations  (10),  radar,  and  communications  capabilities  that  can  be  scaled  and  adapted 
to  multiple  classes  of  Navy  ships  and  submarines.  At  the  heart  of  the  InTop  program  is  the  development 
of  a  modular,  open  architecture  (OA)  that  allows  for  growth  and  change  as  technologies  and  Navy  needs 
evolve.  This  report  discusses  the  initial  development  by  a  joint  Navy/industry  team  of  a  generic  open 
architecture  for  the  InTop  program.  It  defines  the  architecture  components  (building  blocks  and 
interfaces)  and  discusses  insights  gained  into  the  design  and  acquisition  challenges  associated  with 
implementing  an  integrated  topside  using  a  modular  open  systems  approach. 

This  report  is  organized  into  eight  sections.  The  Introduction  (Section  1)  defines  the  broad  objectives 
of  the  study  and  the  study  organization  and  membership.  Sections  2  and  3  describe  an  initial  high-level 
architecture  and  the  types  of  system  requirements  for  communications,  electronic  warfare,  and  radar 
functions.  Section  4  describes  the  primary  work  of  each  of  the  study’s  subgroups:  a  more  detailed 
breakdown  of  the  high-level  architecture.  This  section  forms  the  heart  of  the  report.  It  provides  guidance 
and  a  starting  point  for  InTop  and  future  efforts  on  an  appropriate  level  of  “granularity”  in  dividing  an 
open  radio  frequency  (RF)  system  architecture  into  a  reasonable  set  of  constituent  hardware,  firmware, 
and  software  components.  Section  5  highlights  issues  that  must  be  considered  when  developing  a  new 
open  architecture  system  that  must  interface  with  legacy  equipment  which  may  or  may  not  be  open. 
Sections  6  and  7  conclude  the  report  with  a  discussion  of  the  benefits  and  challenges  to  realizing  the 
vision  of  OA  from  both  a  technical  and  a  business  model  point  of  view.  Section  8  provides  a  list  of 
acronyms  used  throughout  the  report.  The  appendix  lists  study  personnel. 

1.1  The  InTop  Program 

ONR’s  InTop  program  addresses  the  current  condition  in  which  U.S.  Navy  surface  combatants  are 
increasingly  employing  large  numbers  of  federated  RF  apertures  to  perform  electronic  warfare, 
communication,  and  radar  functions.  Each  of  these  functions  (and  hence  individual  systems)  historically 
has  its  own  aperture,  electronics,  operator,  and  logistics/maintenance  tail.  This  classic  stand-alone  RF 
systems  approach  results  in  electromagnetic  interference/compatibility  (EMI/EMC)  problems  that 
degrade  system  performance  and  increase  life-cycle  cost  for  the  combatant.  Additionally,  ship  RF 
signature  and  radar  cross  section  (RCS)  are  difficult  to  reduce  when  restricted  to  stand-alone  RF 
aperture/antenna  approaches.  Most  importantly,  new  communications  and  sensor  requirements  are 
increasing  space,  weight,  and  power  demands  on  the  topsides  and  masts  of  new  platforms,  which 
consequently  leads  to  larger  ships  requiring  increased  generating  capacity  and  incurring  significantly 
higher  cost. 

ONR’s  vision  for  InTop  is  to  provide  Navy  platforms  with  adaptable  RF  capabilities  at  reduced  cost, 
manning,  and  hull  size  by  developing  integrated  sensor  and  communication  solutions  that  are  affordable, 
open,  modular,  and  scalable;  seamlessly  incorporated  into  new  platform  designs  and  structures;  and 
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architected  to  efficiently  grow  with  future  operational  requirements.  InTop  is  geared  primarily  toward 
new  construction  and  Ship  Life  Extension  Programs,  but  where  appropriate  will  also  integrate  with  or 
replace  existing  systems  on  legacy  platforms. 

The  InTop  program  objectives  include  the  following: 

•  Develop,  integrate,  and  demonstrate  new  apertures  and  subsystems  that  will  support  RF 
multifunctionality  and  that  are  based  on  modular,  scalable,  open  architecture,  in  order  to  enable 
greater  flexibility  to  adapt  platform  capabilities  to  rapidly  changing  tactical  and  strategic 
environments. 

•  Demonstrate  the  integration  and  coordinated  control  of  many  critical  shipboard  RF  functions 
implemented  across  a  multitude  of  systems  and  subsystems,  via  a  common  resource  allocation 
manager  (RAM),  in  order  to  optimize  the  use  of  available  RF  spectrum  and  hardware. 

•  Develop,  with  the  Naval  Sea  Systems  Command  (NAVSEA),  ship  design  initiatives  to 
incorporate  InTop  integrated  communications/sensor  systems  to  optimize  ship  size  and 
performance  factors. 


The  goal  of  the  InTop  program  is  to  evolve  to  an  integrated  Navy  capability  10  to  12  years  in  the 
future  that  has  the  following  characteristics: 

•  Modular,  open  RF  architecture 

•  Software-defined  functionality 

•  Synchronized  RF  functions  for  mission  support  and  EMI  mitigation 

•  Reduced  size,  weight,  and  power  requirements  relative  to  a  federated  topside 

•  Reduced  cost  (acquisition  and  total  ownership)  relative  to  a  federation  of  systems 

•  Scalability  in  order  to  derive  systems  of  appropriate  capability  to  match  each  particular  platform’s 
requirements 

•  Reduced  life-cycle  costs 

•  More  RF  functions  optimally  sited  topside 

•  Rapid  adaptability  to  new  threats/requirements  through  software  upgrades 

•  Integrated  antenna/array  topside  designs  that  are  seamlessly  compatible  with  the  associated 
platform  architecture  and  design 


ONR  developed  and  tested  the  integrated  topside  concept  during  the  Advanced  Multifunction  Radio 
Frequency  Concept  (AMRFC)  Program1  initiated  in  1999.  The  Naval  Research  Laboratory  (NRL),  with 
multiple  industry  partners,  integrated  multifunction  transmit  and  receive  arrays  with  generic 
exciter/receivers  and  a  Navy-developed  resource  allocation  manager  at  the  AMRFC  test  bed  in  2004.  Full 
demonstrations  of  multifunction,  simultaneous  operation  of  electronic  warfare  (active  and  passive), 
communications,  and  radar  were  then  conducted  for  Navy  research  and  acquisition  executives. 

AMRFC  was  followed  by  the  Multifunction  EW  (MFEW)  program,2  which  developed  and 
demonstrated  the  ability  to  perform  multiple  electronic  support  (ES)  functions  and  to  incorporate  the 


1  G.  Tavik  et  al.,  “Advanced  Multifunction  Radio  Frequency  Concept  (AMRFC)  Program  Final  Report,”  Naval 
Research  Laboratory  Report  NRL/FR/5303— 07-10,144,  Washington,  DC,  June  2007. 

2  G.C.  Tavik  and  N.M.  Thomas  III,  “The  Multifunction  Electronic  Warfare  (MFEW)  Advanced  Development 
Model,”  2009  NRL  Review  (Naval  Research  Laboratory,  Washington,  DC,  2010),  157-159. 
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ability  to  integrate  with  RAM  and  other  RF  systems.  MFEW  represents  the  initial  system  in  developing 
the  InTop  system  of  systems. 

Initial  tasks  under  the  InTop  program  were  for  the  Navy  to  study  ship  systems  requirements,  and 
jointly  with  industry  to  investigate  the  critical  aspects  of  open  architecture  within  an  InTop  system  of 
systems3  which  will  be  developed  in  a  spiral  approach  over  a  period  of  several  years.  This  report 
addresses  the  open  architecture  issues. 

1.2  Open  Architecture 

Open  architecture  is  considered  critical  to  the  success  of  the  InTop  system  of  systems  concept.  Open 
architecture  is  the  confluence  of  business  and  technical  practices  yielding  modular,  interoperable  systems 
that  adhere  to  open  standards  with  published  interfaces.4  The  critical  features  of  OA5  as  addressed  in  this 
study  include  the  following: 

•  Modular  system  architectures  consisting  of  well-defined  hardware  and  software  components  with 
standard  and/or  government-owned  hardware  and  software  interfaces.  Hardware  components 
include  Ship  Replaceable  Units  (SRUs)  and  Shop  Replaceable/Repairable  Assemblies  (SRAs); 
software  components  include  Computer  Software  Configuration  Items  (CSCIs).6 

•  The  ability  to  develop  new  modular  building  blocks  that  can  be  adapted  to  interface  with  or 
replace  units  in  previously  developed  systems.  This  feature  allows  developers  to: 

•  improve  performance  of  the  base  system  by  adding  or  replacing  components  with 
enhanced  capability  from  multiple  sources; 

•  extend  the  life  of  the  base  system  by  replacing  unsupported  units  with  new,  more  reliable 
and  repairable  units;  and 

•  spirally  integrate  new  InTop  systems  into  previously  developed  InTop  suites  of  systems 
and  associated  resource  allocation  managers. 

•  The  ability  to  scale  InTop  systems  to  accommodate  variable  platform  size,  system,  and 
operational  performance  requirements. 


A  common  misconception  of  OA  is  that  it  is  a  process  to  allow  the  Navy  during  initial  system 
development  to  compete  and  procure  individual  SRUs/SRAs  and  CSCIs  that  may  then  be  integrated  as  a 
system  in  a  manner  similar  to  buying  individual  commercial  off-the-shelf  (COTS)  computer  components 
and  tying  them  together  on  a  common  backplane.  While  this  might  be  possible  in  the  future  if  Navy 


3  The  term  “InTop”  refers  to  the  overarching  InTop  System  of  Systems;  references  to  “InTop  systems”  refer  to 
individual  systems  that  are  considered  to  be  one  (or  more)  of  the  overarching  InTop  System  of  Systems. 

4  Nick  Guertin,  “Instigating  a  Critical  Paradigm  Shift  in  the  Defense  Industry:  Why  Defense  Organizations  Must 
Move  Towards  Contracting  Systems  and  Capabilities  on  an  Open  Architecture  Platform,”  International  Defense 
Logistics  Conference,  4  June  2008;  available  at  https://acc.dau.mil/CommunityBrowser.aspx?id=216795&lang=en- 
US.  Further  information  on  Department  of  the  Navy  requirements,  policies,  and  procedures  for  applying  open 
architecture  principles  may  be  found  at  https://acc.dau.miPoa. 

5  E.M.  Nelson,  Open  Architecture  Technical  Principles  and  Guidelines  1.5.8,  IBM  Coip,  Sept.30,  2008,  available  as 
OA  Architectural  Principles  and  Guidelines  v. 1.5. 8. doc  at 

https  ://acc.dau.mil/CommunityBrowser.aspx?id=170302&lang=en-US. 

6  An  open  architecture  “component”  is  one  of  the  parts  that  make  up  a  system.  A  component  may  be  hardware  or 
software  and  may  be  subdivided  into  other  components;  cf.  Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
Std  610.12-1990.  In  this  study,  we  considered  SRUs  and  CSCIs  to  be  primary  components  (i.e.,  architecture 
“building  blocks”)  and  SRAs  to  be  secondary  components,  as  applicable,  within  SRUs. 
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acquisition  offices  elect  to  take  on  the  responsibility  of  the  system  integrator  and  ultimate  system 
performance,  we  did  not  consider  this  to  be  the  typical  acquisition  strategy  for  the  initial  development  of 
new  systems.  The  process  during  the  initial  development  must  focus  instead  on  identifying  the  modular 
building  blocks  and  their  interfaces  so  that  the  Navy  may  in  the  future  compete,  procure,  and  integrate 
individual  hardware  and  software  components  (or  previously  developed  InTop  systems)  during 
subsequent  iterations  for  improvements  in  both  performance  and/or  life-cycle  cost.  While  maintaining 
focus  on  a  complete  system  development,  a  parallel  development  approach  may  also  be  considered  to 
mitigate  risk  and  validate  critical  interfaces.  Under  this  approach,  selected  critical/high-risk  elements  may 
be  identified  during  the  design  phase,  and  multiple  component  development  and  fabrication  contracts 
competitively  awarded  based  on  the  design  specifications  and  interfaces.  These  components  would  then 
be  integrated  into  the  system  during  the  integration  and  test  (I&T)  phase.  If  possible,  the  second  source 
procurement  should  be  conducted  by  the  prime  contractor,  with  Navy  concurrence,  to  maintain  the 
prime’s  full  responsibility  for  system  performance  and  delivery. 

1.3  The  InTop  Open  Architecture  Study 

For  the  InTop  Open  Architecture  Study,  conducted  in  2008,  four  joint  Navy/industry  teams  were 
established  based  on  the  generic  architecture  of  an  RF  system: 

•  the  Receive/Transmit  Aperture  Subsystem  Study  Group; 

•  the  Radio  Frequency/Intermediate  Frequency  (RF/IF)  Subsystem  Study  Group; 

•  the  Digital  Signal  Processor  (DSP)  and  Data  Processing/Software  (DP/SW)  Subsystems 
Study  Group;  and 

•  the  Resource  Allocation  Manager/Software/Combat  System  (RAM/SW/CS)  Subsystems 
Study  Group. 

A  fifth  team,  the  Integrated  Topside  Oversight  Board  (ITOB),  addressed  system  engineering 
issues  and  provided  technical  and  management  oversight  to  the  four  functional  teams. 

The  teams  were  tasked  to  consider  how  these  four  generic  architecture  blocks  might  be  further 
divided  into  modular  hardware  and/or  software  units  and  interfaces  suitable  for  an  open  architecture.  The 
teams  then  analyzed  the  resulting  modular  architectures  as  they  relate  to  communications  and  sensor 
systems.  This  report  presents  the  results  of  this  analysis  and  provides  comments  and  lessons  learned 
relative  to  open  architecture  as  it  applies  to  the  InTop  program. 

1.4  Expected  InTop  Open  Architecture  Benefits 

The  benefits  of  Integrated  Topside  include  increased  mission  capability,  reduced  ship  costs,  and 
common  systems  across  multiple  platforms.  The  Integrated  Topside  system  of  systems  level  approach 
takes  into  account  not  only  individual  system  performance  requirements  but  all  of  the  RF  system  and  ship 
integration  requirements.  Through  consideration  of  the  complete  set  of  integrated  topside  requirements, 
an  overall  partitioning  and  flow-down  of  system  requirements  can  be  developed.  The  performance  and 
cost  benefits  are  achieved  through  the  efficient  hardware  and  software  implementation  of  these  flowed- 
down  requirements.  With  a  well-designed  open  and  modular  architecture,  an  integrated  topside  will 
provide  a  cost-effective  path  for  platform  scalability,  technology  refresh,  and  open  competition 
throughout  the  life  cycle  of  the  system. 

Scalability  —  Scalability  has  two  distinct  implications.  The  first  is  scalability  through  the  life  of  the 
system  to  pace  the  threat.  A  system  can  have  an  initial  fielding  at  one  level  of  capability,  and  as  the  threat 
or  other  requirements  increase  with  time,  additional  capability  can  be  added  to  the  system  for  both 
forward-fit  and  back-fit  applications.  A  well-designed,  modular,  open  system  enables  scaling  of  multiple 
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regimes  to  increase  capabilities  or  tailor  to  lesser  requirements.  There  can  be  software  upgrades, 
additional  processing  capabilities,  more  channels,  or  a  larger/higher-power  aperture.  The  second  distinct 
form  of  scalability  is  across  different  platforms.  A  scalable  system  can  be  sized  to  meet  the  requirements 
of  large  and  small,  or  highly  capable  and  less  capable  platforms.  This  platform  scalability  leads  to  a  Navy 
surface  enterprise  solution  for  all  ships. 

Life  Cycle/Technology  Refresh  —  The  benefits  of  the  Integrated  Topside  open  architecture 
approach  extend  through  the  life  cycle  of  the  system  and  the  ship.  The  modularity  of  integrated  topside 
systems  allows  the  mission  effectiveness  of  the  ship  and  individual  systems  to  be  improved  to  pace  the 
threat.  The  planned  life  cycle  for  a  single  ship  may  be  up  to  50  years,  and  the  class  life  even  longer.  With 
these  long  life  cycles,  the  ability  to  manage  the  rapid  evolution  of  electronics  technology  is  crucial;  recent 
advances  in  software  open  systems  modularity  must  be  similarly  applied  to  the  electronics  hardware. 
InTop,  therefore,  plans  to  develop  consistent  open  interfaces  at  the  natural  breaks  in  the  architecture,  and 
recognize  that  electronics  that  were  once  advanced  technology  and  the  purview  of  a  few  specialized 
manufacturers  have  become  commodity  components  in  a  relatively  short  time.  The  value  of  this 
modularity  to  life-cycle  management  is  the  ability  to  keep  future  parts  support  at  the  component  level 
open  to  competition  and  alternate  sourcing.  Alternate  sourcing  not  only  encourages  price  competition  but 
also  paces  commercial  technology  advances,  which  are  key  for  maintaining  modem  electronic  systems. 

In  addition  to  logistic  support,  and  competitive  sparing  and  replacement  of  obsolete  parts,  good 
modular  design  allows  for  streamlined  technology  refresh.  With  new  technology  upgrades,  many  legacy 
systems  go  through  a  lengthy  and  costly  qualification  process.  This  process  is  often  a  barrier  to  upgrades 
and  alternate  sourcing.  With  open  interface  modularity,  individual  modules  can  be  qualified  at  the 
component  level,  and  often  for  multiple  systems.  This  level  of  qualification  will  reduce  the  cost  of  re¬ 
qualifying  systems  with  new  technologies  that  pace  the  commercial  electronics  industry. 

Frequency  vs.  Functional  Partitioning  —  While  not  a  specific  function  associated  with  open 
architecture,  the  benefit  of  frequency  partitioning  a  multifunction  system  is  a  significant  factor  in  the 
InTop  architecture.  When  consolidating  functions  into  fewer  apertures,  there  are  several  approaches  that 
can  be  taken.  The  approach  addressed  in  this  study  is  to  consolidate  apertures  into  a  series  of  frequency 
bands,  such  that  each  band  performs  the  selected  RF  functions  required  by  the  ship. 


1.5  Study  Team  Organization 

1.5.1  Leadership  and  Study  Groups 

InTop  leadership  was  provided  by  Program  Manager  Mrs.  Betsy  DeLong  of  the  Office  of  Naval 
Research,  and  Technical  Director  Mr.  Gregory  Tavik  of  the  Naval  Research  Laboratory.  The  InTop  Navy 
and  industry  participants  were  assigned  to  one  or  more  of  the  five  functional  groups  illustrated  in  Fig.  1.5- 
1 ,  based  on  their  particular  expertise. 

The  Integrated  Topside  Oversight  Board  (ITOB)  consisted  of  Navy  and  industry  systems  engineers 
and  program  managers  who  addressed  and  managed  the  system-level  aspects  of  the  study.  Each  of  the 
four  subsystem  study  groups  had  government  and  industry  co-leads  who  provided  both  technical  and 
administrative  direction,  including  documenting  the  group’s  activities.  The  co-leads  of  each  study  group 
were  also  members  of  the  ITOB.  Each  group  was  responsible  for  focusing  on  its  respective  area  while 
simultaneously  dialoging  with  the  other  groups  and  the  ITOB. 
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Fig.  1.5-1  —  InTop  Open  Architecture  Study  organization 


In  addition  to  the  core  study  groups,  several  other  subject  matter  experts  from  Navy  and  industry 
contributed  as  advisors  to  the  teams.  They  had  specific  knowledge  of  ship  or  submarine  components  and 
of  issues  related  to  integration  onto  existing  host  platforms. 

The  study  groups  and  advisors  were  responsible  for 

•  identifying  the  individual  subsystem  architecture  blocks, 

•  identifying  their  associated  interfaces, 

•  incorporating  the  use  of  standards, 

•  establishing  a  generic  architecture  within  their  subsystem  function,  and 

•  identifying  where  there  is  a  lack  of  technology  or  a  need  for  technology  development. 

1.5.2  Study  Group  Responsibilities 

The  InTop  Oversight  Board  focused  on  the  overall  systems  issues  associated  with  establishing  one  or 
more  architectures  to  satisfy  the  multifunction  objectives  of  the  InTop  program.  The  ITOB  generated  and 
managed  requirements,  and  provided  oversight  and  direction  to  the  architecture  subgroups  to  ensure  the 
development  of  a  coherent  system  (or  systems)  and  the  identification  of  appropriate  open  interfaces 
between  the  subassemblies. 

The  Aperture  Subsystem  Study  Group  had  responsibility  for  all  aspects  of  the  antenna,  including  the 
radome,  the  radiator(s),  and  all  functions  leading  to  the  RF  amplification,  beam  steering,  and  control  for 
transmitting  and  receiving  signals.  They  also  were  responsible  for  the  mechanical  installation  issues 
associated  with  the  aperture  installation. 

The  RF/IF  Subsystem  Study  Group  focused  on  all  aspects  of  the  RF  portion  of  the  receiver/exciter. 
On  the  receive  side,  blocks  were  identified  that  provide  an  RF  interface  to  the  antenna,  downconvert  the 
RF  signal  to  an  intermediate  frequency  signal,  digitize  the  IF  signal  with  an  analog-to-digital  converter 
(ADC),  and  pass  the  digitized  IF  samples  to  the  Digital  Signal  Processor  (DSP)  blocks  via  packetized, 
time-stamped  messages.  On  transmit,  blocks  receive  packetized,  time-stamped  messages  from  the  DSP 
blocks,  convert  digital  IF  samples  to  an  analog  IF  signal  through  a  digital-to-analog  converter  (DAC), 
upconvert  the  IF  signal  to  RF,  and  provide  an  RF  interface  to  the  antenna.  Blocks  are  also  identified  that 
mitigate  RF  interference  and  provide  any  required  control  and  calibration. 
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The  Digital  Signal  Processor  and  Data  Processing/Software  (DSP  &  DP/SW)  Subsystems  Study 
Group  focused  on  all  aspects  of  the  digital  signal  and  data  processing.  For  both  transmit  and  receive,  DSP 
blocks  were  identified  that  generate/accept  the  packetized  digital  IF  samples  sent  to/from  the  RF/IF 
subsystem  and  perform  any  digital  signal  processing  required  by  the  selected  function.  The  DP/SW 
subsystem  is  also  responsible  for  implementing  function  controllers  that  request  system  resources  to  be 
allocated  for  radar,  communications,  and  electronic  warfare  functions  and,  once  allocated,  provide  low- 
level  resource  control  to  implement  the  particular  functions. 

The  Resource  Allocation  Manager/Software/Combat  System  (RAM/SW/CS)  Subsystems  Study 
Group  focused  on  all  aspects  of  the  real-time  management  and  allocation  of  the  multifunction  system 
assets  to  maximize  their  utilization  in  accordance  with  priorities  as  assigned  by  the  combat  system  and/or 
higher  authority.  This  includes  integration  of  the  InTop  systems,  and  control,  statusing,  and  related  timing 
and  synchronization  of  the  individual  systems. 

1.5.3  Team  Members 

The  teams  included  members  from  multiple  Navy  organizations  and  nine  industry  companies.  A  list 
of  the  individual  participants  and  advisors  is  provided  in  the  appendix. 

Navy  and  associated  technical  and  management  support  contractors: 

Office  of  Naval  Research 

Naval  Research  Laboratory 

Naval  Sea  Systems  Command 

Naval  Undersea  Warfare  Center  Newport 

Naval  Surface  Warfare  Centers  Dahlgren  and  Carderock 

Space  and  Naval  Warfare  Systems  Center 

INNOLOG,  Inc.  (support  to  ONR  and  NRL) 

ATS  Solutions  (support  to  ONR) 

SAIC  (support  to  PEO  C4I,  PMW  170) 


Industry: 

ATK  Space  Systems,  Inc. 

BAE  Systems 

Ball  Aerospace  &  Technologies  Corp. 

DRS  Signal  Solutions,  Inc. 

General  Dynamics-AIS  (Shenandoah  Solutions,  Inc.) 
Lockheed  Martin  Corp. 

M/A-COM  Technology  Solutions 
Northrop  Grumman  Corp. 

Raytheon  Co. 
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2.  GENERIC  ARCHITECTURE  OVERVIEW 

This  section  examines  a  generic  approach  to  defining  RF  and  digital  building  blocks  that  allow 
developers  to  envision  next-generation  open  architecture  sensor  solutions.  This  will  allow  the  Navy  to 
benchmark  in  a  standardized  framework  the  degree  of  openness  of  each  contractor  during  the  competitive 
and  implementation  phases  of  a  program. 

Fig.  2.0-1  shows  the  four  major  functional  building  blocks  of  a  generic  InTop  architecture: 

•  Aperture 

•  RF/IF 

•  Digital  Signal  Processor  and  Data  Processing/Software 

•  Resource  Allocation  Manager/Software/Combat  System 


It  also  includes  the  interfaces  to  the  platform’s  mechanical/electrical  utilities  and  the  combat  system. 


Aperture  Blocks 
&  Interfaces 
Sub  Group 


Aperture 

RF 

Radomes 

Subsystems 

Combiners 

Dividers 


Signature 

Control 


Power/Thermal/Mechanical 

Subsystems 

RF/IF  Blocks 
&  Interfaces 
Sub  Group 


Signal 
Control  & 
Distrib 


Filtering 


Signal 

Translation  & 
Conversion 


Timing  & 
LO  Ref 


Platform  Utilities  and  Structure 


DSP  and  DP/SW 
Blocks  &  Interfaces 
Sub  Group 

Bulk 

Memory 

Data 

Switching 

General 

Purpose 

Processing 

Special 

Purpose 

Processing 

Configurable 

Processing 

Fig.  2.0-1  —  Generic  InTop  system  block  diagram 


Expanding  on  the  generic  InTop  architecture,  we  can  further  define  a  notional  representation  of  each 
main  functional  block  that  includes  both  physical  and  functional  elements  and  initial  key  interfaces. 
Figure  2.0-2  shows  a  notional  representation  of  an  aperture  subsystem  as  an  example.  Mechanical 
interfaces  are  denoted  as  MICD  (mechanical  interface  control  document).  Electrical  interfaces  (i.e., 
digital,  RF,  power,  and  control)  are  denoted  by  the  color-coded  arrows  between  functional  blocks.  Also 
shown  are  Ship  Replaceable  Units  (SRUs)  and  Shop  Replaceable  Assemblies  (SRAs).  An  SRU  is  a 
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component  in  which  the  Navy  fully  owns  the  interface  definitions,  based  on  open  standards  and  a  detailed 
specification  of  the  block’s  functionality;  an  SRA  is  a  component  within  an  SRU,  that  may  or  may  not 
have  an  open  standard  or  Navy-owned  interface.  Well-defined  SRUs  and  SRAs  within  the  block  diagram 
allow  the  Navy  to  more  quantitatively  benchmark  the  degree  of  openness  of  a  particular  contractor’s 
sensor  architecture. 

The  generic  InTop  block  diagram  was  evaluated  against  surface  ship  and  submarine  radar, 
communications,  and  electronic  warfare  mission  top-level  requirements  to  validate  the  selected  blocks 
and  functions.  The  functions  of  these  four  generic  subsystem  blocks  are  investigated  further,  along  with 
notional  interfaces,  in  Section  4.0. 


■*  *■  RF/IF/Analog  Intrfc  SRU  -  Ship  Replaceable  Unit  SRA  =  Shop  Replaceable  Assembly  MICD  =  Mechanical  ICD 

♦  ■■■»  TBD  Dig  Intrfc  Packetized  Dig  Intrfc  LRM  =  Local  Resource  Manager 


Fig.  2.0-2  —  Notional  InTop  aperture  subsystem  block  diagram 
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3.  GENERIC  REQUIREMENTS  OVERVIEW 

The  InTop  requirements  must  span  a  variety  of  communications,  electronic  warfare,  information 
warfare,  and  radar  needs  for  shipboard  and  submarine  platforms.  General  functions  include  satellite 
communications  (SATCOM),  line-of-sight  (LOS)  communications,  active/passive  EW  and  information 
operations,  and  radar. 

3.1  Satellite  Communications 

An  InTop  satellite  communications  system  should  be  capable  of  simultaneously  linking  with 
multiple  selected  satellites,  including  communicating  with  at  least  one  satellite  in  a  highly  inclined  orbit, 
but  not  necessarily  simultaneously  with  all  the  geostationary  satellites.  It  should,  however,  be  able  to 
communicate  with  one  satellite  in  a  highly  inclined  orbit  and  at  least  one  geostationary  satellite 
simultaneously.  The  receive  array  should  be  such  that  the  G/T  (gain/temperature;  a  measure  of  receiver 
effectiveness)  is  sufficient  to  receive  and  process  the  SATCOM  transmitted  signals,  and  the  transmit  and 
receive  beam  patterns  should  be  such  that  there  is  sufficient  spatial  (tailored  beamwidth)  attenuation  to 
prevent  interference  with  adjacent  satellites.  The  transmit  and  receive  frequencies  are  separate  and  do  not 
overlap.  Beam  pointing  stabilization  and  an  unobstructed  view  of  the  satellites  are  also  critical. 


3.2  Line-of-Sight  (LOS)  Communications 

An  InTop  LOS  communications  system  should  be  capable  of  supporting  a  number  of  simultaneous 
direct  communication  links  at  any  assigned  in-band  frequency  for  ship-to-ship  and  ship-to-air  (or  other) 
networks,  and  ISR  (intelligence,  surveillance,  reconnaissance)  data  links.  It  should  be  backward 
compatible  with  existing  shipboard  radios,  but  also  have  open  interfaces  (RF,  IF,  digital)  that  are  flexible 
enough  to  interface  to  new  radios.  The  architecture  should  address  transmit/receive  isolation  and 
red/black  interface  issues,  provide  a  common  “portal,”  and  operate  under  the  control  of  the  resource 
allocation  manager.  The  LOS  communications  should  be  able  to  effectively  use  the  wideband  InTop  EW 
arrays  on  a  time-share  basis  as  directed  by  the  RAM. 

3.3  Electronic  Warfare  and  Information  Operations 

An  InTop  EW/IO  system  requires  wideband  functionality  for  both  transmit  and  receive.  The  transmit 
aperture  for  EA  should  be  capable  of  engaging  several  simultaneous  threats  with  coherent  and/or  non¬ 
coherent  techniques  at  any  polarity  and  any  frequency  within  the  required  band.  A  receive  aperture  should 
also  have  the  ability  to  form  multiple  beams  to  simultaneously  detect  and  track  threats  at  any  polarity  and 
frequency  within  the  required  band.  While  moderate  receive  directivity  is  required  to  support  coherent  EA 
techniques,  precision  direction  finding  (PDF)  is  required  for  situational  awareness  and  target  hand-off. 


3.4  Radar 

An  InTop  radar  system  should  be  capable  of  supporting  one  or  more  narrow  and/or  wide  transmit 
and  receive  beams  at  any  assigned  in-band  frequency.  It  should  be  capable  of  generating,  receiving,  and 
processing  complex  waveforms  at  multiple  frequencies.  It  should  be  capable  of  performing  track-while- 
scan  surveillance,  precision  tracking  on  multiple  simultaneous  targets,  air  traffic  control,  as  well  as 
electronic  protection  functions.  The  radar  system  will  require  very  high  stability  local  oscillators  and 
clocks  for  high  clutter  rejection  and  should  be  synchronized  to  time  of  day  in  order  to  support  sensor 
network  operations  across  platforms. 

Table  3.0-1  presents  the  key  notional  requirements  for  each  of  the  four  open  architecture 
subgroups/blocks  defined  in  this  study. 
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Table  3.0-1  —  InTop  Subsystem  Notional  Requirements 


Aperture 

RF/IF 

DSP/DP 

Resource 

•  Provide  EIRP  to  close 

•  Out-of-band  RF 

•  Modulation  and 

•  Security 

uplink 

rejection 

demodulation 

•  Initialization  of 

•  Provide  G/T  to  close 

•  Frequency 

schemes 

modem 

downlink 

conversion 

•  Forward  error 

•  Time  server 

Derived 

•  Provide  multiple 

•  Interfaces  to 

correction  (FEC) 

•  Interface  to 

Requirement 

simultaneous  beams 

aperture 

•  Tracking 

combat  system 

•  FOV:  60°  Elevation; 

•  Interfaces  to  DSP 

•  Stabilization 

and  system  control 

360°  Azimuth 

•  Dynamic  range 

•  Backward  and 

consoles 

•  Multi-polarimetric 

•  Noise  temp. 

forward 

•  Dynamic  beam  shaping 

compatibility 

•  Ship  or  submarine  fit 

•  Cooling 

•  Capable  of 

•  Legacy  interfaces 

•  Operating  bandwidth 

•  Interface  to  sail 

running  binary 

•  Hardware  type 

•  Cooling 

•BIT 

copy  of  SATCOM 

•  Software 

Other 

•  Power 

code 

abstraction 

Considerations 

•  Weight 

•  Use  of  legacy  or 

•  MTBF  and 

new  hardware 

serviceability 

•  Software 

•BIT 

abstraction 

EIRP=Effective  isotropically  radiated  power 
FOV=Field  of  view 
MTBF=Mean  time  between  failures 
BIT=Built-in-test 
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4.  DESCRIPTION  OF  ARCHITECTURE  FUNCTIONS  BY  SUBGROUP 

The  following  sections  present  the  individual  architecture  concepts  as  developed  by  the  four 
subgroups. 

4.1  Aperture  Blocks  and  Interfaces 

This  section  contains  the  inputs  of  the  Aperture  Subsystem  Study  Group.  Section  4.1.1  provides  an 
overview  of  a  wide  variety  of  apertures  developed  to  date,  and  their  general  characteristics.  Section  4.1.2 
discusses  a  very  generic  aperture  architecture  block  diagram  that  generally  can  support  any  specific  naval 
aperture  application.  Section  4.1.3  describes  the  top-level  interfaces  required  to  support  this  generalized 
aperture  block  diagram.  Section  4.1.4  gives  a  broad  but  brief  description  of  the  individual  components  of 
the  aperture  block.  Section  4.1.5  provides  a  broad  discussion  of  the  issues  involved  with  mechanical 
integration  of  apertures  into  the  ship  superstructure. 

4.1.1  Aperture  Ovennew 

This  section  provides  a  comprehensive  list  and  brief  description  of  antennas  that  provide  a  steerable 
focused  beam  as  required  by  InTop.  This  exercise  was  intended  to  aid  in  defining  the  various  critical 
assemblies  and  interfaces  in  past,  present,  and  future  apertures.  Twelve  different  aperture  types  were 
identified. 

1.  Single  Feed  Reflector  —  A  conventional  parabolic  reflector  with  a  single  feed  all  mounted  on  a 
mechanical  pedestal.  It  could  also  include  double  reflector  or  shaped  reflector  aperture 
configurations.  Monopulse  feeds  may  also  be  included. 

2.  Multiple  Feed  Reflector  —  This  would  include  systems  with  moving  or  multiple  feeds  to 
produce  scanned  beams.  It  could  include  a  Lewis  scanner  feeding  a  parallel  plate  geodesic  lens 
or  a  drum  scanner  feeding  a  parabolic  reflector.  These  could  also  be  single  or  double  reflector 
systems. 

3.  Switched  Beam  RF  Lens  Phased  Array  —  This  would  typically  include  an  array  of  radiating 
elements  fed  by  a  Butler  Matrix,  Rotman  Lens,  or  Lunenberg  Lens.  Beam  scanning  would  be 
produced  by  switching  between  transmit  (Tx)  input  or  receive  (Rx)  output  ports  to  establish  the 
desired  aperture  amplitude  and  phase  distribution. 

4.  Electronically  Steerable  Reflect  Array  —  A  configuration  similar  to  a  front-fed  reflector  antenna 
where  the  reflector  is  replaced  by  a  series  of  reflect  array  elements.  The  phase  of  the  reflected 
energy  from  each  element  would  be  controlled  to  both  collimate  and  steer  the  beam  and  also 
control  polarization  without  the  use  of  a  beamformer. 

5.  Electronically  Steerable  Transmission  Lens  Array  —  Fixed  beam  transmission  lenses  have  long 
been  used.  They  have  the  advantage  of  eliminating  the  aperture  blockage  associated  with  a  front- 
fed  optical  system  as  well  as  operating  without  a  beamformer.  Transmission  lens  apertures  have 
been  built  which  replace  fixed  phase  shift  elements  with  an  electronically  controlled  phase 
shifter  sandwiched  between  two  radiating  elements.  These  systems  can  support  monopulse 
feeds,  produce  low  side  lobe  levels  (SLLs),  and  maintain  very  stable  beam  pointing  accuracies 
while  still  having  the  advantages  of  pedestal  mounted  operation. 

6.  Conventional  Planar  (Passive)  Phased  Array  —  A  conventional  (coiporate-fed)  phased  array  that 
has  a  phase  shifter  at  each  radiating  element  in  a  planar  or  conformal  array.  The  phase  shifter  at 
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each  element  could  be  controlled  to  both  collimate  and  steer  the  beam.  The  phase  shifters  are  fed 
by  a  beamformer  without  any  amplification  in  the  network.  The  beamformer  network  establishes 
the  array  illumination  taper  which  in  turn  controls  SLL.  Frequently  there  are  separate  Tx  and  Rx 
beamformers  if  different  Tx  and  Rx  SLLs  are  required.  The  concept  of  a  subarray  was  derived 
from  the  number  of  Tx  or  Rx  elements  that  had  the  same  amplitude  illumination.  As  lower  peak 
and  average  SLL  were  required,  the  beamformers  became  more  elaborate,  reducing  the  subarray 
to  one  or  two  elements  and  minimizing  the  array  edge  granularity.  In  addition,  the  phase  shifters 
root  mean  square  (RMS)  phase  error  would  also  be  reduced  to  control  SLL.  With  all  these  array 
configurations,  the  beamformer  and  phase  shifter  loss  must  be  kept  to  a  minimum  to  optimize 
G/T  and  EIRP. 

7.  Electronically  Steerable  Solid-State  Transmission  Lens  Array  —  Transmission  lens  apertures 
have  been  built  which  replace  electronically  controlled  phase  shifters  sandwiched  between  two 
radiating  elements  with  solid-state  transmit/receive  modules.  These  systems  can  also  support 
monopulse  feeds,  produce  low  SLL  and  maintain  very  stable  beam  pointing  accuracies  while 
still  having  the  advantages  of  pedestal  mounted  operation.  In  addition  to  providing  all  the 
advantages  of  the  Electronically  Steerable  Transmission  Lens  Array,  this  aperture  provides  the 
added  capabilities  of  solid-state  phased  arrays.  Specifically,  it  includes  improved  EIRP  (effective 
isotropically  radiated  power)  and  G/T  as  well  as  control  of  amplitude  taper  and  multibeam 
operation.  Aperture  thinning  has  also  been  incoiporated  into  this  configuration  where  EIRP  and 
G/T  were  not  the  driving  requirements. 

8.  RF  Subarray  Solid-State  Planar  Phased  Array  —  This  configuration  is  envisioned  to  be  a 
corporate-fed  Tx  or  Rx  array.  It  locates  the  low  noise  amplifier  (LNA)  and/or  the  high  power 
amplifier  (HP A)  close  to  the  radiating  element  to  reduce  loss  and  noise  figure  (NF).  In  addition, 
it  eliminates  the  large  lossy  beamformer  and  provides  electronic  control  of  array  illumination, 
which  separates  illumination  from  the  subarray  size  and  beamformer  configuration.  This,  in  turn, 
allows  full  flexibility  in  the  selection  of  the  subarray  size  and  configuration.  As  the  size  of  the 
beamformer  shrinks,  multiple  beamformers  can  be  accommodated  in  order  to  support  multiple 
beams. 

9.  Element  Level  Multibeam  Solid-State  Planar  Phased  Array  —  With  the  advent  of  smaller,  more 
efficient  solid-state  components  including  filters,  phase/amplitude  control  devices  and 
monolithic  microwave  integrated  circuit  (MMIC)-based  power  combiners/dividers,  multibeam 
RF  modules  can  be  created  using  LNAs  and  HPAs.  This  architecture  provides  multiple  fully 
independent  beams.  This  can  now  be  accomplished  at  millimeter-wave  frequencies  and  multi¬ 
octave  bandwidths  and  at  element  level.  In  addition,  solid-state  arrays  can  easily  support  division 
of  the  aperture  to  support  a  very  wide  variety  of  configurations. 

10.  Subarray  Level  Multibeam  Solid-State  Planar  Phased  Array  —  This  architecture  is  used  for 
applications  where  some  limitations  can  be  applied  to  multibeam  scan  requirements.  In  these 
cases,  the  number  of  control  devices  could  be  significantly  reduced.  This,  in  turn,  could  reduce 
recurring  costs,  power  consumption,  and  cooling  requirements.  There  are  two  examples  of  this 
condition.  If  lull  scan  were  required  in  one  plane  and  no  scan  were  required  in  the  orthogonal 
plane,  there  could  be  a  significant  reduction  in  the  number  of  control  devices.  As  an  example,  in 
a  10,000-element  array  the  number  of  control  devices  could  be  reduced  from  10,000  to  100,  or  a 
99%  reduction.  This  large  percentage  reduction  would  still  be  true  if  there  were  multiple 
independent  beams  in  the  scan  plane.  With  control  devices  at  100  subarrays,  a  limited  scan  of 
multiple  beams  could  be  achieved  around  the  fixed  array  pointing  also  resulting  in  a  99% 
reduction  in  control  devices.  By  contrast,  if  there  was  a  single  control  device  at  each  radiating 
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element,  and  fixed  beamformers  were  located  at  each  subarray,  multiple  beams  could  be 
clustered  around  the  steered  beam  without  the  addition  of  control  devices. 

11.  Subarray  Level  A/D  and  D/A  (Analog-to-Digital  and  Digital-to-Analog)  Solid-State  Planar 
Phased  Array  —  This  configuration  is  envisioned  to  have  a  solid-state  control  device  at  each 
element  and  A/Ds  and/or  D/As  at  every  subarray.  This  will  permit  multiple  beams  to  be  placed 
around  a  fully  scannable  beam.  The  beams  could  be  located  anywhere  within  the  subarray  beam. 
The  number  of  beams  is  controlled  by  the  control  hardware  and  firmware.  As  a  result,  it  can  be 
expanded  without  altering  the  aperture  hardware. 

12.  Element  Level  A/D  and  D/A  Solid-State  Planar  Phased  Array  —  This  configuration  would  be 
the  ultimate  goal  supporting  very  large  numbers  (hundreds,  thousands)  of  fully  independent 
beams.  This  has  been  implemented  in  the  past  for  UHF  line  arrays.  RF  hardware  and  processing 
limitations  still  leave  this  architecture  for  the  future. 


Table  4.1-1  identifies  the  six  major  building  blocks  included  in  the  twelve  aperture  configurations: 

•  Radome 

•  Structure 

•  Non- Ship-Replaceable  Antenna  Assemblies 

•  Subarray  SRUs 

•  On- Array  Antenna  SRUs 

•  Off-Array  Antenna  Equipment 

Because  of  the  interdependency  between  the  RF/IF  and  DSP  subsystems  with  newer  aperture 
components,  RF/IF  and  DSP  elements  are  also  included  in  this  table. 

Delineating  this  matrix  enables  the  development  of  the  generic  aperture  architecture  presented  in  the 
next  section. 
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Table  4.1-1  —  Matrix  of  Aperture  Configurations 


Single  Feed  Reflector 

Multiple  Feed 
Reflector 

Switched  Beam  RF 
Lens  Phased  Array 

Electronically 

Steerable 

Reflect  Array 

Radome 

Antenna  Radome 

Antenna  Radome 

Antenna  Radome 

Antenna  Radome 

Structure 

Structure 

Structure 

Structure,  Power.  Logic  & 
Cooling  Distribution 

Structure,  Power,  Logic  & 
Cooling  Distribution 

Non-ship- 

replaceable 

Antenna 

Assembllies 

Reflector 

Reflector 

Reflector 

Reflect-Array  Elements 

Feed  Radome 

Feed  Radome 

Feed  Radome 

Feed  Radome 

Feed 

Feed  &  Rotator 

Lens  Assy 

Feed 

W/G  &  RJ 

W/G  &  RJ 

Subarray  SRUs 

On- Array 
Antenna 
SRUs 

Switch  Assy 
&  Drivers 

Phase  Shifter  Drivers 

Distributed  BSC 

Distributed  BSC 

On-Array 

DC  to  DC 

On-Array 

DC  to  DC 

Duplexer 

Duplexer 

Duplexer 

Duplexer 

On-Array 

Tx  Drivers 

On-Array 

Tx  Drivers 

On-Array  LNAs 

On-Array  LNAs 

Off- Array 
Antenna 
Equipment 

Pedestal  &  Pedestal 
Control 

Pedestal  &  Pedestal 
Control 

Pedestal  &  Pedestal 
Control 

Pedestal  &  Pedestal 
Control 

Off-Array  Tx  Beamformers 

Off-Array  Tx  Beamformers 

Off-Array 

BSC 

Off-Array 

BSC 

Off-Array 

Power  System 

Off-Array 

Power  System 

Off-Array 

Cooling  System 

Off-Array 

Cooling  System 

RF/IF  Subsystem 

Exciter  & 

Tx  Power  Amp 

Exciter  & 

Tx  Power  Amp 

Exciter  & 

Tx  Power  Amp 

Exciter  & 

Tx  Power  Amp 

Rx  Protector 
&  LNAs 

Fix  Protector 
&  LNAs 

Rx  Protector 
&  LNAs 

Rx  Protector 
&  LNAs 

RF  to  IF 
Converters 

RF  to  IF 
Converters 

RF  to  IF 
Converters 

RF  to  IF 
Converters 

IF  to  Digital  Converters 

IF  to  Digital  Converters 

IF  to  Digital  Converters 

IF  to  Digital  Converters 

Digital  Signal 
Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 

16 


Tavik  et  al. 


Table  4.1-1  (cont.)  —  Matrix  of  Aperture  Configurations 


Electronically 

Steerable 

Transmission  Lens 
Array 

Conventional  Planar 
Phased  Array 

Electronically 
Steerable 
Solid-State 
Transmission  Lens 
Array 

RF  Subarray  Solid- 
State 

Planar  Phased  Array 

Radome 

Antenna  Radome 

Antenna  Radome 

Antenna  Radome 

Antenna  Radome 

Structure 

Structure,  Power,  Logic  & 
Cooling  Distribution 

Structure,  Power,  Logic  & 
Cooling  Distribution 

Structure,  Power,  Logic  & 
Cooling  Distribution 

Structure,  Power,  Logic  & 
Cooling  Distribution 

Non-ship- 

replaceable 

Antenna 

Assembllies 

Lens  Assy 
(Phase  Shifters) 

Element 

Radomes 

Lens  Assy 

Radiating  Elements 

Lens  Enclosure 

Radiating 

Elements 

Lens  Assy 

Tx/Rx  Modules 

Lens  Enclosure 

Lens  Enclosure 

Tx/Rx  Modules  in 
Subarray 

Feed 

Feed 

Subarray 

Electronics 

Subarray  &  Cal. 
Beamformers 

Subarray  SRUs 

On- Array 
Antenna 
SRUs 

Phase  Shifters 

Phase  Shifter  Drivers 

Phase  Shifter  Drivers 

Power 

Conditioning 

Subarray  Power 
Conditioning 

Distributed  BSC 

Distributed  BSC 

Distributed  BSC 

Distributed  BSC 

On-Array 

DC  to  DC 

On-Array 

DC  to  DC 

On-Array 

DC  to  DC 

On-Array 

DC  to  DC 

Duplexer 

On-Array  Beamformers 

On-Array  Beamformers 

On-Array 

Tx  Drivers 

On-Array 

Tx  Drivers 

On-Array 

Tx  Drivers 

On-Array  LNAs 

On-Array  LNAs 

On-Array  LNAs 

On-Array  LNA 

Off -Array 
Antenna 
Equipment 

Pedestal  &  Pedestal 
Control 

Off-Array  Tx  Beamformers 

Off-Array  Tx  Beamformers 

Off-Array  Tx  Beamformers 

Off-Array  Tx  Beamformers 

Off-Array 

BSC 

Off-Array 

BSC 

Off-Array 

BSC 

Off-Array 

BSC 

Off-Array 

Power  System 

Off-Array 

Power  System 

Off-Array 

Power  System 

Off-Array 

Power  System 

Off-Array 

Cooling  System 

Off-Array 

Cooling  System 

Off-Array 

Cooling  System 

Off-Array 

Cooling  System 

RF/IF  Subsystem 

Exciter  & 

Tx  Power  Amp 

Exciter  & 

Tx  Power  Amp 

Exciter  & 

Tx  Power  Amp 

Exciter 

Rx  Protector 
&  LNAs 

Fix  Protector 
&  LNAs 

Fix  Protector 
&  LNAs 

Fix  Protector 
&  LNAs 

RF  to  IF 
Converters 

RF  to  IF 
Converters 

RF  to  IF 
Converters 

RF  to  IF 
Converters 

IF  to  Digital  Converters 

IF  to  Digital  Converters 

IF  to  Digital  Converters 

IF  to  Digital  Converters 

Digital  Signal 
Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 
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Table  4.1-1  (cont.)  —  Matrix  of  Aperture  Configurations 


Element  Level 
Multibeam 
Solid-State 
Planar  Phased  Array 

Subarray  Level 
Multibeam 
Solid-State 
Planar  Phased  Array 

Subarray  Level 

A/D  &  D/A 
Solid-State 

Planar  Phased  Array 

Element  Level 

A/D  &  D/A 
Solid-State 

Planar  Phased  Array 

Radome 

Antenna  Radome 

Antenna  Radome 

Antenna  Radome 

Antenna  Radome 

Structure 

Structure,  Power,  Logic  & 
Cooling  Distribution 

Structure,  Power,  Logic  & 
Cooling  Distribution 

Structure,  Power.  Logic  & 
Cooling  Distribution 

Structure,  Power,  Logic  & 
Cooling  Distribution 

Non-ship- 

replaceable 

Antenna 

Assembllies 

Radiating  Elements 

Radiating  Elements 

Radiating  Elements 

Radiating  Elements 

Tx/Rx  Modules  in 
Subarray 

Tx/Rx  Modules  in 
Subarray 

Tx/Rx  Modules  in 
Subarray 

Subarray 

Electronics 

Subarray 

Electronics 

Array 

Electronics 

Multiple  Subarray 
Beamformers 

Overlapped  Subarray 
Beamformer 

Subarray  SRUs 

Subarray  Power 
Conditioning 

Subarray  Power 
Conditioning 

On- Array 
Antenna 
SRUs 

Tx/Rx  Modules  & 
Beamformers 

Multiple  Array  Beamformers 

Array  Power 
Conditioning 

Subarray  Power 
Conditioning 

Distributed  BSC 

Distributed  BSC 

On-Array 

DC  to  DC 

On-Array 

DC  to  DC 

On-Array 

DC  to  DC 

On -Array 

DC  to  DC 

Multiple  On-Array 
Beamformers 

Multiple  On-Array 
Beamformers 

On-Array 

Tx  Drivers 

On-Array 

Tx  Drivers 

D/A 

Converter 

D/A 

Converter 

On-Array  LNA 

On-Array  LNA 

RF  to  Digital  Converters 

RF  to  Digital  Converters 

Off- Array 
Antenna 
Equipment 

Off-Array  Tx  Beamformers 

Off-Array  Tx  Beamformers 

Off-Array 

BSC 

Off-Array 

BSC 

Off-Array 

BSC 

Off-Array 

Power  System 

Off-Array 

Power  System 

Off-Array 

Power  System 

Off-Array 

Power  System 

Off-Array 

Cooling  System 

Off-Array 

Cooling  System 

Off-Array 

Cooling  System 

Off-Array 

Cooling  System 

RF/IF  Subsystem 

Exciter 

Exciter 

Rx  Protector 
&  LNAs 

Fix  Protector 
&  LNAs 

RF  to  IF 
Converters 

RF  to  IF 
Converters 

IF  to  Digital  Converters 

IF  to  Digital  Converters 

Digital  Signal 
Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 

Digital 

Signal  Processor 
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4.1.2  Generic  Aperture  Architecture  Block  Diagram 

Traditionally,  military  electronic  systems  like  radar,  EW,  and  communications  have  included 
proprietary  designs.  These  designs  are  usually  not  easily  scalable  or  upgradeable  and  do  not  offer  the 
advantage  or  the  economy  of  a  modular  open  systems  approach.  The  first  major  task  of  the  Aperture 
Subsystem  Study  Group  was  to  develop  a  generic  aperture  architecture  that  would  be  applicable  to 
existing  and  future  naval  surface  ship  and  submarine  applications.  Furthermore,  generic  interfaces  that 
would  support  this  architecture  had  to  be  defined.  Developing  such  an  architecture  presented  a  formidable 
task,  as  there  are  many  different  antenna  types  that  could  be  used  for  a  specific  application.  In  fact,  the 
architecture  had  to  be  general  enough  so  as  not  to  preclude  potential  or  unforeseen  future  aperture 
solutions.  However,  with  the  following  assumptions,  the  group  developed  the  generic  aperture  block 
diagram  shown  in  Fig.  4.1-1: 

•  That  all  possible  aperture  components  should  be  included  in  the  diagram.  This  would  allow  the 
greatest  flexibility  in  implementing  or  tailoring  the  diagram  for  a  specific  application.  In  the  event 
a  particular  component  is  not  required  for  a  particular  application,  it  is  simply  omitted.  For 
example,  phase/amplitude  control  is  not  applicable  and  therefore  goes  away  for  parabolic 
reflector  systems. 

•  That  interfaces  between  components  may  disappear  or  be  combined  with  other  components  for 
specific  applications.  For  example,  an  FNA  and  phase  shifter  may  be  combined  on  a  single 
gallium  arsenide  (GaAs)  MMIC. 

•  That  the  order  of  the  components  may  change  depending  on  the  specific  interface  boundaries 
between  major  subsystems.  For  example,  under  one  set  of  requirements  the  antenna  elements  for 
a  phased  array  radar  application  may  be  integrated  into  the  ship  superstructure  with  the  interface 
to  the  RF  electronics  defined  as  a  standard  connector.  Under  another  set  of  requirements,  the 
complete  aperture  for  a  receive-only  20  GHz  phased  array  may  have  all  of  the  components 
(including  a  radome,  signature  control,  antenna  elements,  and  the  combiner  networks)  integrated 
into  a  single  subarray  and  supplied  as  a  single  unit. 
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TBD  Dig  Interface 


Packetized  Dig  Interface  LRM  =  Local  Resource  Manager 


Fig.  4.1-1  —  Generic  aperture  architecture  block  diagram 


4.1.3  Aperture  Components 

The  generic  aperture  block  diagram  shown  in  Fig.  4.1-1  has  a  number  of  components  identified.  As 
discussed,  some  of  these  components  may  or  may  not  be  present  in  a  particular  system,  and  some  of  these 
components  may  be  combined  with  others  for  another  particular  system.  This  section  discusses  the 
general  properties  of  each  of  the  major  components  that  could  possibly  comprise  an  aperture  subsystem. 

4.1.3.1  Radome 

Radomes  can  be  designed  to  provide  several  functions  for  the  system.  They  protect  the  antenna  and 
electronics  from  the  external  environment  while  minimizing  degradation  to  the  desired  RF  signal.  The  RF 
signals  are  the  inputs  and  outputs  of  the  radome.  Radomes  may  have  active  control  for  non-RF  functions 
(such  as  de-icing).  Future  radomes  may  exhibit  active  control  for  radar  cross  section,  insertion  loss  vs. 
scan,  or  polarization  compensation.  Design  considerations  include  RF  insertion  loss,  infrared  (IR) 
signature,  RCS,  visual  signature,  mechanical  integration,  and  environmental  durability  (including  thermal, 
chemical,  biological,  nuclear,  and  ballistic). 

4.1.3.2  Signature  Control 

Signature  control  is  a  critical  feature  in  apertures.  It  is  used  to  minimize  the  signals  at  RF,  IR,  and 
optical  frequencies  to  a  specified  level  and  typically  requires  special  treatment  techniques  and  materials. 
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The  RF  signals  are  the  inputs  and  outputs  of  the  signature  control  block.  RF  signals  include  not  only  those 
generated  by  the  antenna,  but  also  those  generated  by  the  threats.  Future  signature  control  may  be  actively 
controlled.  Design  considerations  include  selective  signal  attenuation,  IR  signature  control,  visual 
signature  control,  mechanical  integration,  and  edge  treatments. 

4.1.3.3  Antenna 

The  antenna  transitions  RF  energy  from  free  space  to  electrical  conductor  and  vice  versa.  The 
antenna  could  be  a  single  element,  array  of  elements,  or  other  structure  (reflector,  slotted  waveguide 
array,  etc.).  The  RF  signals  are  the  inputs  and  outputs  of  the  antenna.  Future  antennas  could  consist  of  an 
active  element  (implying  that  some  physical  or  electrical  characteristic  of  the  antenna  element  itself  is 
varied  to  provide  a  change  in  a  core  performance  parameter)  or  a  reconfigurable  antenna  element.  Design 
considerations  include  efficiency,  directivity,  radiation  pattern,  bandwidth,  polarization,  RCS,  impedance, 
voltage  standing  wave  ratio  (VSWR),  electrical  size,  power  handling  capability,  mechanical  integration, 
weight,  volume,  and  heat  dissipation. 

4.1.3.4  Isolation  Control 

The  isolation  control  component  protects  RF  electronics  from  unwanted  signals,  and  may  include 
isolators,  circulators,  filters,  limiters,  diplexers,  switches,  etc.  The  input  signals  include  the  RF  inputs  and 
the  control  signals,  and  the  output  is  the  RF  signal.  RF  signals  not  only  include  those  generated  by  the 
antenna,  they  also  include  those  generated  by  the  neighboring  antennas  and  threats.  The  control  would 
include  any  switch  control  signals.  A  status  signal  might  include  BIT.  The  design  considerations  include 
the  isolation  and  rejection  of  undesired  signals,  the  insertion  loss  of  desired  signals,  power  handling 
capability,  and  heat  dissipation. 


4.1.3. 5  Amplifiers 

Amplifiers  boost  the  desired  signals  for  transmit  or  receive  conditioning.  The  inputs  to  an  amplifier 
include  the  RF  signals  and  DC  power.  The  outputs  include  RF  signal(s).  Possible  control  is  required  for 
power  leveling  and  on/off  control.  Status  might  include  BIT  (i.e.,  VSWR,  current  draw,  temperature, 
etc.).  Design  considerations  include  signal  gain,  VSWR,  power  handling  capability,  noise  figure  (a  metric 
of  degradation  of  signal-to-noise  ratio  [SNR]  caused  by  components  in  the  amplifier),  third  order 
intercept  (TOI;  a  metric  of  amplifier  linearity)  point,  power  added  efficiency  (PAE;  a  metric  of  power 
amplifier  efficiency),  bandwidth,  heat  dissipation,  and  spurious  emissions. 

4.1.3. 6  Phase  and  Amplitude  Control 

Phase  control  is  employed  to  electronically  steer  an  array  antenna’s  main  beam.  Specifically,  relative 
phases  between  elements  in  an  array  are  adjusted  to  collect/radiate  signals  to/from  the  array  in  a  particular 
direction.  Amplitude  control  is  used  to  control  the  SLL  of  the  array  radiation  pattern.  These  side  lobes  are 
simply  the  unwanted  energy  not  in  the  main  beam  of  the  aperture.  SLL  can  be  reduced  via  an  amplitude 
taper;  the  antenna  gain,  however,  decreases  as  well  with  the  use  of  a  taper. 

Together,  phase  and  amplitude  control/modify  the  desired  signal  for  beamsteering,  polarization 
control,  pattern  control,  and  calibration.  Phase  shifters,  time  delay  units,  and  attenuators  are  typically 
used.  The  inputs  include  RF  signals  and  DC  power.  The  outputs  are  the  RF  signals.  The  control  elements 
include  control  signals  and  calibrations.  Status  includes  BIT.  Design  considerations  include  isolation  and 
rejection,  insertion  loss,  power  handling  capability,  accuracy  and  resolution,  calibration,  heat  dissipation, 
bandwidth,  and  polarization  purity. 
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4.1.3.7  Combiner/Divider  Network 

Combiner/divider  networks  route  the  signal(s)  to/from  the  desired  number  of  channels  and  to/ffom 
the  various  antenna  elements  making  up  the  antenna  subsystem.  For  most  applications,  these  networks 
must  include  amplifier  stages  to  overcome  their  associated  losses.  These  gain  stages  allow  the  receive 
system  to  maintain  the  system  noise  figure  set  by  the  initial  LNA  and  the  transmit  system  to  drive  the 
output  power  amplifiers  to  their  desired  power  level.  These  networks  can  be  realized  in  waveguide,  coax, 
microstrip,  or  stripline  circuits  and  any  combination  thereof.  Phase  and  amplitude  control  components 
may  be  used  to  maintain  signal  integrity.  The  inputs  include  RF  signals  and  DC  power.  The  outputs  are 
the  RF  signals.  The  control  elements  include  control  signals  and  calibrations.  Status  includes  BIT.  Design 
considerations  include  insertion  loss,  power  handling  capabilities,  accuracy  and  resolution,  calibration, 
group  delay,  time  delay,  heat  dissipation,  bandwidth,  and  size  and  weight. 


4.1.3.8  Antenna  Controller 

For  an  array,  the  antenna  controller  is  a  beam  steering  computer  (BSC).  The  BSC  converts  raw  or 
partially  processed  beam  steering  data  to  control  signals  that  can  be  distributed  to  the  aperture  for  final 
beam  pointing.  This  computer  may  utilize  localized  inertial  measurement  unit  (IMU)  information  for 
aperture  pointing  correction,  localized  or  global  calibration  factors,  and  global  IMU  data.  Signal  strength 
feedback  from  an  IF  processing  interface  may  be  used  for  active  correction  as  well.  Also,  the  modem  may 
supply  the  computer  with  commands  to  correct  for  factors  such  as  frequency  dependent  beam  steering 
commands. 


4.1.3.9  Power  Conditioning 

Typical  platforms  have  a  common  power  source  to  supply  power.  This  voltage  is  often  optimized  for 
distribution  and  not  necessarily  for  the  operation  of  electronic  components.  Additionally,  since  multiple 
systems  may  be  operating  off  this  same  power  bus,  spurious  signal  transmission  from  system  to  system 
must  be  minimized.  Most  electronic  components  operate  at  low  DC  voltages,  with  the  exception  of  some 
HPAs,  and  therefore  require  some  voltage  conversion  from  the  optimal  distribution  voltages  to  these 
lower  values.  In  this  conversion  process,  the  power  is  usually  filtered  to  prevent  any  “noise”  generated  by 
the  electronics  to  be  transmitted  to  the  power  grid  and  vice  versa. 

4.1.4  Generic  Aperture  Block  Interfaces 

The  major  interfaces  of  this  generic  aperture  subsystem  include  the  structuraFmechanical  interface  to 
the  ship,  the  interface  to  the  ship  utilities  (power,  cooling,  etc.),  the  resource  allocation  manager  interface, 
and  the  RF/IF  interface.  In  addition,  there  may  be  specific  interfaces  supporting  legacy  equipment.  These 
broad  types  of  interfaces  are  discussed  in  the  sections  that  follow. 

4. 1,4.1  Mechanical  Interfaces 

Mechanical  Interface  Control  Documents  are  shown  in  the  generic  block  diagram  in  several  locations 
representing  general  requirements.  These  locations  may  change  depending  on  the  specific  requirements. 
For  example,  for  a  single  subarray/array  module  that  contains  all  of  the  components  integrated  into  a 
“tile,”  the  only  interface  would  be  between  that  tile  and  the  ship.  On  the  other  hand,  where  the  individual 
components  are  individually  packaged  and  integrated  into  the  aperture,  there  may  be  numerous  interfaces 
to  the  ship  and/or  aperture  structure.  A  radome,  for  example,  may  be  supplied  and  integrated  into  the  ship 
structure  independent  of  the  signature  control,  while  the  antenna  elements,  as  well  as  power  amplifiers, 
phase  shifters,  etc.,  may  have  a  separate  interface.  Similarly,  inertial  measurement  unit  data  is  required  to 
actively  steer  the  aperture.  Depending  on  the  specific  antenna  requirements,  the  IMU  may  need  to  be 
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located  at  the  aperture  (correcting  for  errors  due  to  ship  flexure),  or  even  at  the  subarray  level  (to  correct 
for  errors  between  electrically  large  subarrays). 

4.1.4.2  Ship  Utility  Interfaces 

Interface  Control  Documents  (ICDs)  are  required  for  the  ship  utilities.  These  include  electrical  power 
(specifying  voltage,  power,  signal  purity,  etc.)  and  cooling  (liquid,  air,  and  all  associated  specifications 
such  as  temperature,  type  of  coolant,  flow  rates,  etc.). 

4. 1.4.3  Resource  Allocation  Manager  (RAM)  Interfaces 

ICDs  are  required  for  the  RAM.  These  documents  include  all  command  messages,  BIT,  status,  etc. 
required  to  operate  the  system.  These  interfaces  should  be  open  and  based  on  a  scalable,  upgradeable, 
commercial  technology. 

4. 1.4.4  RF/IF  Interfaces 

RF/IF  ICDs  are  required.  They  should  specify  the  RF  signal  characteristics  expected  to/from  the 
aperture,  as  well  as  any  control,  status,  or  BIT  data. 

4.1.4.5  Other  Interfaces 

Most  likely,  some  legacy  RF  subsystems  and  systems  will  be  reused  on  future  naval  vessels.  Figure 
4.1-1  shows  a  translator  that  must  be  developed  to  interface  the  legacy  system  with  the  new  antenna. 

4.1.5  Mechanical  Integration  of  Antennas 

The  Aperture  study  group  also  looked  at  mechanical  engineering  issues  related  to  an  antenna.  These 
include  cooling  requirements,  protection  from  the  natural  environment  and  shocks,  structural  stiffness, 
manufacturability,  maintainability,  and  ship/submarine  installation. 

The  mechanical  integration  of  sensors  for  the  next  generation  of  ships,  such  as  the  Zumwalt  class 
shown  in  Fig.  4.1-2,  has  many  new  challenges  due  to  the  closed  deckhouse  architecture.  The  closed 
deckhouse  is  desired  for  improved  survivability  based  on  better  signature  control,  but  drives  the  sensors 
to  be  planar  and  much  more  integrated  into  the  mechanical  structure  of  the  ship. 

The  integrated  sensors  in  this  example  must  meet  ship  requirements  such  as: 

•  Low  signature  (blended  to  ship  structure  for  IR,  visible,  and  RCS) 

•  Structural  load  bearing  for  ship  loads 

•  EMI  shielding  between  inside  and  outside  of  ship 

•  Water  tightness  and  green  water  loads 

•  Foundation  flatness  and  stiffness 
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Fig.  4.1-2  —  Zumwalt  Class  destroyer 


The  integrated  sensors  also  must  meet  the  antenna  requirements  of: 

•  Array  flatness 

•  Element  spacing  tolerances 

•  Clean  power 

•  Cooling 

•  Corrosion  prevention 

•  Antenna  loads  (shock,  vibration,  gun  blast,  green  water,  and  overpressure) 


The  integrated  sensors  must  meet  the  integration  requirements  of: 

•  Co-site  interference  among  antennas  with  limited  deckhouse  area 

•  Mounting  height  requirements 

•  Corrosion  due  to  dissimilar  ship  and  antenna  materials 

•  Lightning  protection  for  ship  and  antennas 

•  Integrated  structural  loads  due  to  coefficient  of  thermal  expansion  mismatch  and  seaway 
loads 

To  meet  all  the  individual  and  integrated  requirements  with  reasonable  recurring  and  non-recurring 
cost,  common  sensor  interfaces  must  be  used.  For  this  to  be  done  effectively,  interfaces  must  be 
considered  before  the  sensors  are  designed.  Figure  4.1-3  shows  a  modular  mechanical  architecture  for  the 
sensor  interfaces  indicated  in  the  generic  aperture  block  diagram  (Fig.  4.1-1).  This  implementation  uses 
an  integrated  ship  structure  as  the  antenna  structure.  The  architecture  also  shows  potential  locations  of  the 
hardware  items  required  to  meet  performance.  The  radome  and  signature  control  must  be  exposed  to  the 
outside  environment  with  the  antenna  radiator  in  close  proximity.  Since  the  radiators  typically  have  to  be 
arranged  on  a  half-wavelength  lattice,  a  dilation  layer  may  be  required  for  interconnections  to  the  inside 
electronics.  An  interface  layer  may  be  required  to  meet  flatness  requirements.  Electronic  functions  located 
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inside  the  ship  would  include  amplification,  phase  and  amplitude  control,  power  combination/division, 
and  power  conditioning.  Locating  these  items  inside  the  ship  structure  allows  for  the  easiest  maintenance. 

Higher-frequency  antennas  may  require  electronics  mounted  on  the  outside  of  the  ship  structure;  in 
these  applications,  the  dilation  layer  shown  in  Fig.  4.1-3  would  be  replaced  with  the  electronics  shown 
inside  the  structure. 


Dilation  may  be  needed  if  the  spacing  between  the 


Fig.  4.1-3  —  Modular  mechanical  architecture  for  an  antenna  subsystem 


Interfaces  to  the  antenna  electronics  include  high  voltage  power  for  antenna  amplifiers/electronics, 
house  power  for  less  demanding  electronics,  and  liquid  and  air  cooling  distribution.  These  interfaces  need 
to  be  standardized  to  assure  reliability  and  serviceability  with  a  minimal  amount  of  unique  spares  and  part 
numbers.  Standard  interfaces  for  the  antenna  controller,  digital  IF,  and  utility  and  signal  integration  are 
most  important  as  antenna  functionality  and  scheduling  becomes  more  integrated  and  shared.  Common 
interfaces  also  allow  individual  components  to  be  refreshed  as  advanced  technology  becomes  available. 

Figure  4.1-4  shows  how  the  architecture  can  be  scaled  from  a  single-cell  small  array  to  a  multi-cell 
large  array.  This  type  of  platform  integration  method  avoids  the  large  structural  cutouts  in  the  deckhouse 
superstructure  which  were  common  for  Zumwalt  aperture  installations.  Large  cutouts  weaken  the 
deckhouse  structure  and  require  the  antennas  or  array  plates  to  handle  increased  loads  from  the 
deckhouse. 
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Large  Multi-Cell  Array 


Fig.  4.1-4  —  Scalable  architecture 


Figure  4.1-5  shows  the  concept  scaled  up  to  the  entire  face  of  a  deckhouse.  This  allows  for  antenna 
growth  as  threats  evolve  and  for  sensor  replacement  as  new  technologies  become  available.  It 
presupposes  that  throughout  a  ship’s  life,  a  large  portion  of  the  deckhouse  area  may  be  used  for  sensor 
integration.  Complete  utilization  of  deckhouse  area  maximizes  PA  (power  x  aperture)  and  PAG  (power  x 
aperture  x  gain)  products  for  radars,  and  G/T  and  EIRP  for  communications  systems. 

In  regard  to  large  arrays  that  must  be  integrated  into  the  topside,  the  InTop  OA  Study  participants 
agreed  in  principle  that  it  is  desirable  to  establish  standard  mechanical  and  structural  interfaces  for  InTop 
above-deck  subsystems.  Such  standards  will  facilitate  deckhouse  design  and  implementation,  and 
simplify  the  integration  of  multiple  arrays  into  the  topside  structure.  Also,  even  though  the  technology 
refresh  cycle  for  arrays  is  not  envisioned  to  be  as  short  as  it  is  for  back-end  components  (e.g.,  DSP 
modules),  this  standardization  will  facilitate  upgrades  of  the  array  SRUs  as  related  technologies  advance. 

This  concept  is  represented  in  Fig.  4.1-1  by  the  MICD  designations  associated  with  the  Radome/FSS 
(Frequency  Selective  Surface)/Subaperture  SRUs.  In  addition  to  standardizing  these  mechanical 
interfaces,  consideration  was  also  given  to  the  concept  of  modularizing  them.  An  OA  implementation  of 
standardized  platform  structural  and  mechanical  interfaces  might  take  the  form  of  a  truss-like  structure 
with  one  of  a  select  number  of  “modular”  grid  sizes  onto  which  subarray  panels  (or  non-functional 
panels)  can  be  mounted.  The  grid  would  provide  significant  structural  load-bearing  properties  and  could 
even  include  liquid  cooling  thermal  manifolds  to  accommodate  the  heat  load  of  the  array.  Notional 
depictions  of  this  concept  are  shown  in  Figs.  4.1-5  and  4.1-6. 
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Basic  Ship  Superstructure 
and  Interfaces 


Subscale  (Panel)  Structure 
and  Interfaces 


Fig.  4.1-5  —  Scalable  deckhouse  antenna  structure.  Modular  interfaces  allow  individual  components  to  be  refreshed  as  the 
technology  improves  and  allow  customization  at  the  panel  and  subpanel  levels  to  support  multiple  antenna  technologies. 


Fig.  4.1-6  —  Notional  modular  structural  interface 
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4.2  RF/IF  Blocks  and  Interfaces 

The  RF/IF  functional  block  provides  the  bidirectional  transport  of  the  signal(s)  between  the  aperture 
functional  block  and  the  DSP  subsystem  functional  block  of  the  Integrated  Topside  system.  Within  the 
RF/IF  block,  the  signal  may  be  subjected  to  various  operations  which  can  broadly  be  categorized  as 

•  signal  control, 

•  signal  distribution  (analog  and  digital), 

•  signal  filtering, 

•  frequency  generation,  and 

•  frequency  conversion. 

These  operations  can  be  considered  the  subsystems  of  the  RF/IF  functional  block. 

In  the  receiver,  the  transported  signal  can  be  subjected  to  any  number  of  these  operations.  For 
example,  the  frequency  may  be  converted  from  the  RF  signal  received  from  the  aperture  to  an 
intermediate  frequency  which  is  provided  to  the  DSP  subsystem.  This  IF  signal  may  be  either  analog  or 
digital,  or  both.  Additionally,  in  the  receiver,  the  signal  may  be  subjected  to  amplification,  filtering,  and 
other  signal  conditioning  operations. 

In  the  transmitter,  a  reverse  set  of  operations  may  take  place.  The  transported  signal  frequency  may 
be  converted  from  an  IF  signal  received  from  the  DSP  subsystem  (either  analog  or  digital,  or  both)  to  the 
RF  signal  provided  to  the  aperture. 

These  two  simplified  cases  are  presented  to  demonstrate  the  concept  of  the  functional  building 
blocks  that  may  be  active  in  the  RF/IF  function.  The  RF/IF  Subsystem  Study  Group  has  identified  a  set  of 
building  blocks  and  interfaces  that  describe  the  individual  elements  that  make  up  the  RF/IF  function. 
These  building  blocks  can  be  used  to  describe  the  functions  required  within  an  SRA  or  SRU  when 
developing  a  procurement  requirement  document  for  the  physical  components  of  the  RF/IF  function  for 
Integrated  Topside  subsystems.  The  building  blocks  are  the  following: 

•  Downconverter  (including  analog  to  digital  conversion) 

•  Upconverter  (including  digital  to  analog  conversion) 

•  Oscillator/synthesizer 

•  Distribution 

•  Switch 

•  Transport  (analog  and  digital) 

•  Coherent  canceller 

•  Coherent  combiner 

•  Filter 

•  Interface  translator 

•  Power  conditioning 


These  building  blocks,  shown  in  Fig.  4.2-1,  are  described  in  detail  in  Section  4.2.1  with 
consideration  given  to  their  inputs,  outputs,  control,  and  status  signals.  Examples  of  notional 
downconverter  and  upconverter  blocks  are  shown  in  Fig.  4.2-2  and  Fig.  4.2-3,  respectively. 
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Oscillator  / 
Synthesizer 


Precision 

Analog 

Transport 


Resource  Control  subsystem  is  a  function  of 
the  system  Resource  Allocation  Manager 


Coherent 

Canceller 


Coherent 

Combiner 


Digital 


Power 

Resource 

Conditioning 

Control* 

Interface 

Translator 


Fig.  4.2-1  —  RF/IF  subsystem  components 


With  the  emergence  and  continued  advancement  of  high-speed  digitization  approaches,  it  is  also 
possible  to  realize  significant  aspects  of  the  RF/IF  functionality  in  the  digital  domain.  A  direct  digital 
up/down-conversion  may  take  place  at  the  antenna  element  level,  moving  a  significant  amount  of 
traditional  RF  functionality  into  the  aperture  functional  block.  In  this  case,  much  of  the  functionality 
described  in  the  RF/IF  functional  block  will  occur  in  the  digital  domain.  This  results  in  significant 
blurring  of  the  lines  of  the  aperture,  RF/IF,  and  DSP  functional  blocks,  with  the  ultimate  possibility  of  the 
combination  of  all  functions  in  the  aperture  at  the  element  level. 
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Aperture  RF/IF  Subsystem  DSP 


Power 


Fig.  4.2-2  —  Notional  RF/IF  (downconverter)  chain 


Aperture 

Subsystem 


RF/IF  Subsystem  DSP 


Fig.  4.2-3  —  Notional  RF/IF  (upconverter)  chain 


30 


Tavik  et  al. 


4.2.1  RF/IF  Building  Block  Functions 

4.2. 1.1  Downconverter 


Signal  Input 
LO  1...N 
ADC  Clock 


> 

+• 

> 


Downconverter 


Signal 
*  Output 


General  Description 

The  downconverter  translates  a  signal  from  one  frequency  to  another,  optionally  providing  gain 
and/or  attenuation,  and  filtering.  The  output  signal  is  nominally  at  a  lower  frequency  referenced  to  the 
input  signal.  Input  is  always  an  analog  signal  at  a  center  frequency  ranging  from  millimeter-wave  to  near 
DC.  Output  may  be  either  analog  at  an  intermediate  frequency,  or  a  digital  representation  of  an  IF  signal 
out  of  an  analog-to-digital  converter,  or  both.  Typically  for  modem  systems  with  digital  processing  the 
output  will  be  digital.  In  some  cases  of  advanced  realizations,  where  very  wideband  ADCs  are  used,  some 
digital  preprocessing  of  the  signals  may  be  required  before  transport  of  the  digital  signal. 


Parameters 

Input 

•  Analog  signal 

•  Local  oscillators  (LO)  1  . . .  N 

•  ADC  clock 

Output 

•  Analog  signal,  or 

•  Digital  signal  (out  of  ADC),  or 

•  Both 

Control 

•  Gain  /  attenuation  /  blanking,  possibly  as  a  function  of  time 

•  Input  frequency  or  band  select 

•  Bandwidth  select  /  filter  control 

Status 

•  Input  signal  level  overdrive  flag 

•  LO  level 

•  Temperature 

•  BIT 
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4.2. 1.2  Upconverter 


Signal  Input 
LO  1...N 
DAC  Clock 


> 

>• 

> 


Upconverter 


Signal 
>  Output 


General  Description 

The  upconverter  translates  a  signal  from  one  frequency  to  another,  optionally  providing  gain  and/or 
attenuation,  and  filtering.  The  output  signal  is  almost  always  at  a  higher  frequency  referenced  to  the  input 
signal.  The  output  is  always  an  analog  signal  at  a  center  frequency  ranging  from  millimeter-wave  to  near 
DC.  The  input  may  be  either  an  analog  signal  at  an  intermediate  frequency,  or  a  digital  signal  in  the  form 
of  either  real  intermediate  frequency  samples  or  complex  in-phase  and  quadrature  baseband  samples  that 
are  used  to  drive  the  upconverter.  Typically  for  modem  systems  with  digital  processing,  the  input  will  be 
digital.  In  some  cases  of  advanced  realizations  where  very  wideband  digital-to-analog  converters  are 
used,  some  digital  preprocessing  of  the  signals  may  be  required  to  allow  for  digital  signal  transport. 


Parameters 

Input 

•  Analog  signal,  or 

•  Digital  data  representing  the  signal 

•  Local  oscillators  1  . . .  N 

•  DAC  clock 

Output 

•  RF  analog  signal 
Control 

•  Gain  /  attenuation  /  blanking,  possibly  as  a  function  of  time 

•  Output  frequency  or  band  select 

•  Bandwidth  select  /  filter  control 

Status 

•  Output  signal  level  or  overdrive  flag 

•  LO  level 

•  Temperature 

•  BIT 
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4.2. 1.3  Oscillator/Synthesizer 


SYS  REF 
1  PPS 


*• 

► 


Oscillator  / 
Synthesizer 


► 


LO  1...N 

ADC/DAC  Clock 


General  Description 

The  oscillator/synthesizer  generates  one  or  more  local  oscillator  frequencies  and  clocks  that  are 
phase  coherent  to  a  system  reference  signal.  Referred  to  as  a  local  oscillator,  or  LO,  its  output  is  always 
an  analog  signal  that  is  typically  a  fixed  frequency  sinusoid,  but  may  also  be  a  chirped  sinusoid.  In  some 
cases,  a  1  PPS  (pulse  per  second)  input  signal  or  other  precision  timing  signal  will  also  be  required  where 
there  is  a  need  for  the  output  LO  signals  to  always  have  the  same  phase  relationship  with  respect  to  the 
system  reference  signal. 


Parameters 

Input 

•  System  reference  signal 

•  1  PPS  reference/precision  timing  signal 

Output 

•  Analog  LO  signals 

•  Digital  clock(s) 

Control 

•  Output  frequency 

•  Output  phase 

•  Start  frequency,  stop  frequency,  start  phase,  sweep  duration 

•  Frequency  vs.  time  profile 

Status 

•  Phase-locked  loop  (PLL)  lock  status 

•  LO  power  level 

•  Temperature 

•  BIT 
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4.2. 1.4  Distribution 


Input  Signal  1 
Input  Signal  M 


> 

> 


Distribution 

M:N 


*• 

► 


Output  Signal  1 
Output  Signal  N 


General  Description 

The  distribution  block  generates  N  channels  of  analog  signals  from  M  input  channels  of  analog 
signals.  It  may  contain  amplification  or  attenuation  functions  internal  to  the  block.  Examples  include  LO 
distribution  trees,  where  a  distribution  subsystem  would  combine  with  a  transport  subsystem  to  move  the 
output  of  an  oscillator/synthesizer  to  multiple  sites  for  connection  to  multiple  RF/IF  subsystem 
upconverters  and  downconverters. 

Parameters 

Input 

•  M  analog  signals 
Output 

•  N  analog  signals 
Control 

•  Gain  /  attenuation  control 

•  Output  enable 

Status 

•  Saturation  detect 

•  Temperature 

•  BIT 
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4.2. 1.5  Switch 


Input  Signal  1 
Input  Signal  M 


Switch 

M:N 


Output  Signal  1 
Output  Signal  N 


General  Description 

The  switch  block  in  its  most  generic  form  routes  M  channels  of  analog  input  signals  to  N  channels  of 
analog  output  signals.  It  can  also  be  configured  to  select  one  output  signal  from  M  channels  of  input 
signals. 


Parameters 

Input 

•  M  analog  signals 
Output 

•  N  analog  signals 
Control 

•  Input  to  output  routing 

•  Open  /  close 

Status 

•  Temperature 

•  BIT 
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4.2. 1.6  Precision  Analog  Transport 


Input  Signal  1 
Input  Signal  N 


- ► 

Precision 

- ► 

Analog 

Transport 

► 

► 


Output  Signal  1 
Output  Signal  N 


General  Description 

In  the  context  of  the  RF/IF  subsystem,  the  precision  analog  transport  block  moves  an  analog 
RF/microwave  signal  from  one  physical  location  to  another.  It  may  be  waveguide,  coax,  fiber,  or  other 
medium.  It  is  meant  to  represent  only  those  analog  signal  transport  cases  where  there  is  a  precision 
requirement  such  as  phase  matching  or  tracking  across  multiple  channels,  equalized  channel  response 
across  frequency,  etc.  In  the  case  of  fiber,  the  coherent  lasers  and  the  electro-optic  modulators  and 
demodulators  are  assumed  to  reside  within  the  transport  subsystem.  N  channels  of  transport  are  achieved 
by  aggregating  N  transport  channels. 


Parameters 

Input 

•  1  to  N  channels  of  RF/microwave  signal 
Output 

•  1  to  N  channels  of  RF/microwave  signal 
Control 

•  Input  to  output  routing 

•  Open  /  close 

Status 

•  Temperature 

•  Power  monitor 

•  BIT 
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4.2. 1.7  Digital  Transport 


Input  Signal  1 
Input  Signal  N 


Digital 

Transport 


Output  Signal  1 
Output  Signal  N 


General  Description 

In  the  context  of  the  RF/IF  subsystem,  the  digital  transport  block  moves  a  digital  representation  of  1 
to  N  channels  of  RF/IF  signals  from  one  physical  location  to  another.  Multiplexing  and  demultiplexing 
functions,  if  used,  are  assumed  to  exist  within  the  digital  transport  system.  It  is  used  to  represent  the 
interface  between  the  RF/IF  system  output  and  the  processing  system  input. 


Parameters 

Input 

•  1  to  N  channels  of  digitally  represented  RF/IF  signals 
Output 

•  1  to  N  channels  of  digitally  represented  RF/IF  signals 
Control 

•  Input  to  output  routing 
Status 

•  Bit  error  rate 


InTop  Open  Architecture  Study 


37 


4.2. 1.8  Coherent  Canceller 


Corrupted  Input 
Signal 

Coherent  Replica 
Signal 


- ► 

Coherent 

- ► 

Canceller 

w 

Corrected  Output 
Signal 


General  Description 

In  the  context  of  the  RF/IF  subsystem,  the  coherent  canceller  receives  as  input  both  an  analog  input 
signal  that  has  been  corrupted  by  a  second  signal  and  an  analog  or  digital  coherent  replica  of  this  second 
corrupting  signal.  The  coherent  canceller  functions  by  adding  the  corrupted  signal  with  the  appropriate 
amplitude  and  time  and  phase  delay  based  on  the  replica  to  generate  an  output  signal  that  is  free  (ideally) 
of  the  corrupting  signal. 


Parameters 

Input 

•  One  analog  channel  of  corrupted  RF/microwave  signal 

•  Analog  or  digital  coherent  replica  signal 

Output 

•  One  channel  of  corrected  RF/microwave  signal 

Control 

•  Enable 

Status 

•  Temperature 

•  Power  monitor 

•  Cancellation  ratio  estimate 

•  BIT 
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4.2. 1.9  Coherent  Combiner 


Input  Signal  1  - ► 

Coherent 

Input  Signal  N  - ► 

Combiner 

w 

Output  Signal 


General  Description 

In  the  context  of  the  RF/IF  subsystem,  the  coherent  combiner  receives  as  input  two  or  more  analog 
RF/microwave  input  signals  that  are  derived  from  the  same  source  but  are  potentially  time  delayed  and 
phase  shifted  with  respect  to  each  other.  The  coherent  combiner  functions  by  adding  the  two  signals  with 
the  appropriate  time  and  phase  delay  to  generate  an  output  signal  that  is  maximized  in  signal-to-noise 
ratio.  This  block  is  typically  used  to  coherently  combine  signals  off  adjacent  receive  array  faces  that  are 
each  steering  beams  to  the  same  transmit  location.  This  is  done  to  avoid  the  loss  in  sensitivity  that  occurs 
when  an  array-based  antenna  scans  off  boresight.  This  coherent  combiner  may  also  be  implemented 
operating  on  complex  baseband  digital  data,  in  which  case  it  would  reside  within  the  DSP  subsystem. 


Parameters 

Input 

•  N  channels  of  analog  RF/microwave  signals 
Output 

•  One  channel  of  SNR  optimized  RF/microwave  signal 
Control 

•  Steering  commands 

•  Enable 

Status 

•  Temperature 

•  Power  monitor 

•  Combined  SNR  estimate 

•  BIT 
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4.2.1.10  Filter 


Input  Signal 


Filter 

w 

w 

Output  Signal(s) 


General  Description 

The  filter  accepts  an  analog  input  signal  and  routes  it  to  a  network  whose  amplitude  and/or  phase 
varies  as  a  function  of  frequency.  The  filter  can  be  either  a  single  device  with  fixed  characteristics,  a 
single  device  whose  parameters  (center  or  cutoff  frequency  and/or  bandwidth)  can  be  changed  under 
system  control,  or  multiple  fixed  devices  arranged  into  a  filter  bank.  While  other  RF/IF  blocks  may 
contain  filters,  such  as  the  upconverter  and  downconverter  blocks,  this  function  may  also  be  stand-alone 
and  provides  for  the  inclusion  of  emergent  filter  technologies  into  the  Integrated  Topside  architecture.  It 
may  be  inserted  into  a  system,  but  not  be  tightly  integrated  within  the  existing  functions. 


Parameters 

Input 

•  One  channel  of  analog  RF/microwave  signal 
Output 

•  1  (or  more)  channels  of  RF/microwave  signal  with  modified  characteristics 
Control 

•  Channel  select,  center  frequency  select,  bandwidth  select 
Status 

•  Temperature 

•  Power  monitor 

•  BIT 
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4.2.1.11  Interface  Translator 


System  Reference 
Precision  Timing  Signal 
Control  /  Status 


Interface 

Translator 


-* 


> 


*- 


> 


Timing  Trigger 

Serial  /  Parallel 
Control 

Control  /  Status 


General  Description 

The  interface  translator  accepts  timing  signals  and  control  messages  from  the  system  controller,  and 
generates  RF/IF  subsystem  hardware-friendly  timing  triggers,  serial  and  parallel  control  signals,  and 
control  and  status  lines.  There  may  be  more  than  one  interface  translator  per  RF/IF  subsystem. 


Parameters 

Input 

•  System  control  and  status  signals  (may  be  Ethernet) 

•  Precision  timing  signal  (typically  1  PPS) 

•  System  reference  timing  (typically  1 0  MFIz) 

Output 

•  Digital  timing  triggers 

•  Digital  serial  and  parallel  control 

•  Status 

Control 

•  Messages  from  system  controller 

Status 

•  BIT 
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4.2.1.12  Power  Conditioning 


Raw  Input 


Power 

w 

Conditioning 

w 

Conditioned  Output 


General  Description 

In  the  context  of  the  RF/IF  subsystem,  the  power  conditioning  block  takes  in  system  supply  power  in 
the  form  of  AC  or  DC,  and  converts  it  to  a  form  that  is  suitable  for  use  by  the  individual  RF/IF 
subsystems. 

Parameters 

Input 

•  AC  or  DC  system  supply  power 
Output 

•  AC  or  DC  power  to  SRAs  or  SRUs  in  the  RF/IF  subsystem 
Control 

•  Power  on/off 
Status 

•  Temperature 

•  Power  monitor 

•  BIT 
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4.3  DSP  and  DP/SW  Subsystems  and  Interfaces 

This  section  provides  an  overview  of  the  Digital  Signal  Processor  and  Data  Processing/Software 
subsystems,  including  descriptions  of  the  different  types  of  processing  elements,  function  controllers  and 
interfaces. 

The  DSP  subsystem  is  responsible  for  high-rate  signal  processing  functions  for  radar, 
communications,  and  electronic  warfare/information  operations  applications.  It  supports  high-bandwidth 
digital  interfaces  to  and/or  from  the  RF/IF  subsystem.  The  RF/IF  interface  consists  of  digitized  sample 
data  in  real  or  complex  format  which  is  converted  between  digital  and  analog  form  via  analog-to-digital 
converter  or  digital-to-analog  converter  assets  within  the  RF/IF  subsystem.  The  processing  elements  are 
the  following: 

•  Configurable  processing  elements  (CPEs),  such  as  field-programmable  gate  arrays  (FPGAs) 

•  General-purpose  processing  elements  (GPPEs),  such  as  Power  PCs 

•  Special-purpose  processing  elements  (SPPEs),  such  as  legacy  cryptologic  processors,  or 
application-specific  integrated  circuits  (ASICs) 


The  DP/SW  subsystem  is  responsible  for  executing  function  controller  applications  implemented  in 
GPPEs.  The  InTop  function  controllers  are  the  following: 

•  Radar  function  controller  (RFC) 

•  Communications  function  controller  (CFC) 

•  EW/IO  function  controller  (EFC) 

The  function  controllers  are  not  additional  hardware  components,  but  rather  a  software 
implementation  of  the  specific  functions  in  the  hardware  resources.  The  function  controllers  are  typically 
implemented  in  general-purpose  processors  to  effect  higher-level  controls  for  each  of  the  functions 
described  above.  General-purpose  processors  would  typically  be  removed  from  the  pool  of  dynamically 
allocatable  processors  used  as  GPPEs  and  dedicated  to  executing  the  persistent  processing  required  to 
implement  tasks  such  as  function  controllers  and  the  resource  allocation  manager  itself.  Examples  of  the 
DP/SW  operations  performed  by  the  radar  function  controller  include  interfacing  to  the  operator  and 
combat  system,  target  tracking,  antenna  pointing  control,  and  establishment  of  surveillance  fences  and 
volumes. 

The  utilization  of  the  processing  elements  and  other  resources  by  a  function  controller  can  be 
dynamically  allocated  via  requests  to  the  resource  allocation  manager  described  in  Section  4.4. 

4. 3. 1  DSP  Subsystem  Processing 

This  section  describes  the  processing  hardware  and  software  required  to  implement  the  DSP 
subsystem. 

4.3. 1.1  DSP  Subsystem  Processing  Blocks 

The  DSP  subsystem  consists  of  three  classes  of  processing  resources  and  two  types  of  infrastructure 
resources.  The  three  classes  of  processing  resources  are  configurable  processing  element,  general-purpose 
processing  element,  and  special-purpose  processing  element.  The  two  infrastructure  resources  are  a  data 
switching  element  and  a  bulk  memory  element.  Figure  4.3-1  shows  these  resources  in  a  notional  block 
diagram  with  interfaces  to  the  resource  allocation  manager,  the  RF/IF  converter  modules,  and  the  IF/RF 
converter  modules.  The  RAM  interface  is  via  a  Gigabit  Ethernet  (GE)  link  and  is  used  primarily  as  a 
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means  for  the  RAM  to  transport  low-rate  configuration  commands,  status  reports,  and  one  or  more  time 
references.  The  RAM  interface  does  not  perform  real-time  command  and  control  of  resources.  It  allocates 
the  resources  to  function  controllers  for  communications,  radar,  and  EW  within  the  DSP  block  to  perform 
real-time  control  of  resources.  The  controller  for  each  function  may  be  executed  in  one  of  the  processing 
resources  in  the  DSP  block  or  distributed  across  multiple  processing  elements.  The  interface  between  the 
processing  elements  and  the  RF  to  IF  converter  (RF/IF)  and  the  IF  to  RF  converter  (IF/RF)  uses  the 
VITA-49  format,  also  referred  to  as  VRT  (VITA  Radio  Transport),  for  real-time  flow  of  signal  data  and 
control/status.  In  this  transport  layer  format,  the  signal,  control,  and  status  data  are  conveyed  in  time- 
stamped  packets,  which  eliminates  the  need  for  custom  timing  and  synchronization  hardware  signals 
within  the  architecture.  Further  information  on  VRT  can  be  obtained  at  www.DIGITALIF.org  or 
www.VITA.com. 

This  report  does  not  prescribe  how  the  digital  IF  interfaces  from  the  RF/IF  and  IF/RF  resources  are 
connected  to  the  processing  elements.  The  digital  interfaces  may  be  interfaced  to  any  of  the  processing 
resources  or  to  the  data  switch.  The  physical  interface  may  combine  multiple  channels  of  data  across  a 
single  interface  or  it  may  utilize  a  single  physical  interconnect  for  each  RF  channel.  These  details  are  to 
be  prescribed  at  the  discretion  of  the  architect  for  each  platform  implementation. 


RF  Analog  Signal 

RAM  Ctrl/Status  -  GEethernet 


□ 

□ 

■ 

LI 


Non-DSP  Element 
DSP:  Signal  Processing  Card 
DSP:  Data  Switch 
DSP:  Bulk  Memory 


Fig.  4.3-1  —  DSP  resource  interfaces 
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4.3. 1.1.1  Special-Purpose  Processing  Element  (SPPE) 

The  SPPE,  shown  in  Fig.  4.3-2,  is  a  placeholder  for  legacy  processing  resources  and  is  typically  not 
reconfigurable.  An  example  of  a  special-purpose  processing  element  would  be  a  legacy  communication 
modem  such  as  the  Enhanced  Bandwidth  Efficient  Modem  (EBEM).  Cryptographic  processors  will  be 
another  class  of  SPPE  due  to  their  unique  packaging  and  security  requirements.  These  devices  have 
dedicated  functionality  with  a  fixed  set  of  operating  modes.  It  is  assumed  that  an  interface  “wrapper”  (an 
InTop  Interface  Module)  will  be  required  to  connect  legacy  (non-InTop)  devices  to  other  InTop 
subsystems. 


Data  1/0(1)  « - 

•  • 


Data  l/0(N)  < 


Fig.  4.3-2  —  SPPE  block  diagram 
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4.3.1 . 1 .2  Configurable  Processing  Element  (CPE) 

The  CPE  (Fig.  4.3-3)  is  envisioned  to  be  an  FPGA-based  programmable  device.  It  will  be  utilized  for 
highest  rate  signal  processing  functions,  typically  fixed-point  operations  directly  at  the  ADC/DAC  sample 
rate.  Typical  CPE  functionality  will  include  digital  downconversion,  finite  impulse  response  (FIR)  and 
polyphase  filtering,  and  digital  beamforming.  CPE  synchronization  will  be  on  the  order  of  0.1  to  10 
microseconds. 

FPGAs  are  set  up  to  perform  specific  tasks  by  loading  them  with  a  configuration  file  that  specifies 
how  the  various  onboard  resources  are  connected  and  synchronized.  An  FPGA  might  need  to  be  loaded 
with  one  configuration  to  perform  a  radar  processing  task,  for  example,  and  then  loaded  with  a  separate 
configuration  to  perform  an  EW  task.  Typically,  the  various  configurations  an  FPGA  would  be  expected 
to  perform  are  stored  in  flash  memory  onboard  the  CPE.  Current-technology  FPGAs  can  be  reconfigured 
in  this  fashion  in  about  100  milliseconds,  and  this  time  needs  to  be  taken  into  account  during  a  context 
switch.  Alternatively,  depending  on  the  application  and  the  FPGAs  used,  it  is  possible  to  have  one  FPGA 
configuration  contain  the  processing  required  for  multiple  applications.  In  this  case,  it  would  be  possible 
to  switch  between  various  onboard  processing  chains  in  the  order  of  microseconds. 

FPGA  cards  typically  contain  several  FPGAs  with  pre-defined  I/O  structures.  For  such  cards,  the 
designer  could  choose  to  either  make  the  entire  card  a  CPE  or  make  each  FPGA  on  the  card  a  CPE  and 
apportion  the  available  I/O  among  the  FPGAs. 
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Fig.  4.3-3  —  CPE  block  diagram 


4.3.1 . 1 .3  General-Purpose  Processing  Element  (GPPE) 

The  GPPE  (Fig.  4.3-4)  is  envisioned  to  be  a  programmable  processing  board  consisting  of  one  or 
more  (4  to  16  typically)  general-purpose  microprocessors  with  shared  memory  and  a  high  bandwidth 
inter-processor  interconnect  fabric.  Application  software  running  under  a  real-time  operating  system  will 
define  GPPE  functionality.  It  is  expected  that  these  real-time  operating  systems  will  be  open  architecture 
if  possible.  Since  reconfiguration  simply  consists  of  a  software  context  switch,  the  GPPE  is 
reconfigurable  on  a  time  frame  of  <1  microsecond  (assuming  multiple  applications  are  co-resident  in 
GPPE  memory).  The  GPPE  will  typically  be  used  for  “frame  rate”  processing  with  processing  batches 
representing  >10  milliseconds  (typical)  of  sensor  timeline.  Typical  GPPE  processing  will  be  fixed  or 
floating  point  operations  on  time-ordered  batches  of  data.  Typical  functions  implemented  in  the  GPPE 
include  matched  filtering,  interleaving/deinterleaving,  error  coding/decoding,  target  detection,  signal 
classification,  and  angle-of-arrival  calculation.  GPPE  synchronization  will  be  on  the  order  of  0.1  to  2 
milliseconds. 


Data  1/0(1)  ◄ - ► 

•  • 

General-Purpose 

•  • 

Processing 

•  • 

Element 

Data  l/0(N)  ^ - * 

I 


Control/Status/Time 


Fig.  4.3-4  —  GPPE  block  diagram 
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4.3.1 . 1 .4  DSP  Subsystem  Infrastructure  Elements 

The  DSP  subsystem  infrastructure  resources  consist  of  a  broadband  data  switch  and  a  bulk  memory 
resource. 

The  broadband  data  switch  provides  high-bandwidth,  low-latency,  packet-switched  interconnect 
between  multiple  DSP  processing  elements,  and  between  DSP  processing  elements  and  bulk  memory. 
The  broadband  data  switch  shall  use  commercial  open  standard  interfaces  supporting  at  a  minimum  the 
following: 


•  Layer  2  switching 

•  Port  bandwidths  of  1-10  Gbps 

•  Remote  direct  memory  access  (RDMA)  capability 

•  Port-to-port  latency  on  the  order  of  2  x  105  bit  times 

•  Routing  header  overhead  <5% 

•  Line  coding  overhead  <25%  (<5%  goal) 

•  Support  optical  or  copper  (short  range)  physical  interfaces 

•  Roadmap  to  40-100  Gbps 


Internet  Protocol  (i.e.,  Ethernet),  Infiniband,  and  Serial  RapidIO  all  meet  these  minimum 
requirements.  The  use  of  the  VRT  protocol  layer  shall  be  transparent  to  DSP  switches.  It  is  recommended 
that  this  switch  be  able  to  support  one-to-many  mirroring  of  the  data  paths. 

The  bulk  memory  resource  provides  high-bandwidth  data  buffering  to  and  from  the  data  switch  and 
DSP  processing  assets.  The  bulk  memory  resource  must  support  single-  and  dual-port  operation  (goal: 
quad-port)  in  both  FIFO  (first  in,  first  out)  and  DMA  (direct  memory  access)  modes. 

4.3. 1.2  DSP  Subsystem  Software 

There  will  be  a  real-time  software  component  within  the  GPPE,  SPPE,  and  CPE  building  blocks.  For 
the  SPPE,  software  will  execute  within  the  InTop  Interface  Module  (see  Fig.  4.3-2). 

As  a  minimum,  this  real-time  software  will  be  hosted  on  an  embedded  processor  and  control  the 
following  functions: 

•  Built-in-test 

•  Initialization 

•  Command  interface 

•  Fligh-order  timing  control  and  synchronization 

•  Context  switch  control 

•  Status  reporting 


Within  the  CPE,  FPGA  configuration  and  reconfiguration  will  be  under  software  control.  These 
processing  elements  will  be  used  to  provide  processing  that  is  sample  rate  critical  such  as  pulse 
processing  of  ultra-wideband  signals.  They  may  also  be  used  to  perform  some  of  the  same  functions  as 
the  GPPE! 

Within  the  GPPE  block,  all  signal  and  data  processing  functions  will  be  implemented  via  software 
applications  executing  on  one  or  more  digital  signal  processors  or  general-purpose  microprocessors. 
Functions  implemented  by  the  GPPE  software  applications  may  include,  but  are  not  limited  to  the 
following: 
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•  Channelization 

•  Digital  downconversion 

•  Equalization 

•  Matched  filtering 

•  Waveform  generation 

•  Target  detection 

•  Adaptive  weight  calculation 

•  Signal  line  coding/decoding/demodulation 


These  software  applications  will  use  message-based  communications  provided  by  a  communications 
infrastructure.  This  infrastructure  will  be  composed  of  operating  system,  middleware,  and  common 
computing  and  networking  services,  such  as  time  distribution,  synchronization,  resource  management, 
messaging,  data  recording,  and  distribution  of  navigational  data.  A  standard  set  of  application  program 
interfaces  (APIs)  will  be  defined  for  those  services  required  by  the  DSP  software  applications.  Wherever 
possible,  the  definition  of  APIs  will  be  standards-based  and  not  be  vendor  or  technology  dependent. 

4.3.2  DP/S  W  Subsystem  Processing 

This  section  describes  the  processing  hardware  and  software  required  to  implement  the  DP/SW 
subsystem. 

4.3.2.1  DP/SW  Subsystem  Processing  Blocks  (Function  Controllers) 

The  primary  purpose  of  the  DP/SW  subsystem  in  an  InTop  architecture  is  to  provide  control  of  the 
various  InTop  functions.  Mission-specific  function  controllers  are  instantiations  of  software  on  one  or 
more  general-purpose  processors.  General-purpose  processors  would  typically  be  removed  from  the  pool 
of  dynamically  allocatable  processors  used  as  GPPEs  and  dedicated  to  executing  the  persistent  processing 
required  to  implement  tasks  such  as  function  controllers  and  the  resource  allocation  manager  itself.  The 
function  controllers  would  be  allocated  on  a  semi-permanent  basis  by  the  RAM/SW/CS  subsystem.  They 
may  in  fact  request  resources  from  the  RAM  to  effect  a  surveillance  or  track  action. 

4.3.2.2  DP/SW  Subsystem  Software 

Generic  function  controllers  provide  higher-level  control  for  the  radar,  communication,  and  EW/IO 
missions.  Where  the  DSP  processing  elements  operate  and  preserve  context  in  time  frames  on  the  order  of 
10  microseconds  to  100  milliseconds,  the  function  controllers  operate  in  time  frames  of  10  milliseconds 
to  hours.  Where  a  DSP  block  could  be  allocated  for  the  duration  of  a  single  radar  coherent  dwell  at  a  time, 
its  associated  radar  function  controller  would  detect  and  track  an  air  target  over  minutes  and  hours.  Figure 
4.3-5  illustrates  where  the  function  controllers  would  reside  in  the  context  of  an  InTop  system. 

When  the  appropriate  complement  of  aperture,  RF/IF,  and  DSP  assets  has  been  allocated,  the 
function  controller  will  “take  over”  and  coordinate  the  steps  required  to  perform  a  specific  radar, 
communication,  or  EW/IO  action.  The  function  controllers  will  operate  loosely  decoupled  from  real  time. 
Fine-grained  actions  will  be  scheduled  by  the  controller  with  explicit  time-of-action  tags.  Similarly, 
results  from  the  DSP  blocks  will  carry  time-of-execution  tags.  Synchronization  with  real  time  will  be  on 
the  order  of  ±10  milliseconds. 
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Fig.  4.3-5  —  DSP  subsystem  and  function  controllers  within  InTop  context 


4. 3.2. 2. 1  Radar  Function  Controller  (RFC) 

The  RFC  is  responsible  for  controlling  one  or  more  radar  missions.  This  controller  is  implemented  as 
a  software  application  hosted  on  a  general-purpose  processor  (typically  a  microprocessor-based  GPPE). 
The  software  application  will  execute  under  a  real-time,  preferably  open  architecture,  operating  system.  It 
is  responsible  for  higher-level  functionality.  It  receives  commands  from  the  combat  system,  requests 
assets  from  the  RAM,  and  sources  time-stamped  action  commands  to  its  allocated  aperture,  RF/IF,  and 
DSP  subsystems.  It  transmits  processed  results  (status  and  target  data)  to  the  combat  system.  For 
example,  the  RFC  could  receive  a  high-level  command  such  as  volume  air  surveillance  which  includes 
commands  for 


azimuth  (min, max), 
elevation  (min, max),  and 
range  (min, max). 
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The  low-level  radar  functions  supportable  by  the  RFC  include  the  following: 

•  Raster  generation 

•  Antenna  pointing 

•  Waveform  selection 

•  Radar  scheduling 

•  Target  tracking 

•  Object  discrimination/classification 

•  Satellite  ephemeris  and  penetration  list  calculation 

•  Environmental  monitoring  (interference)  and  mitigation 

•  Emission  control  (EMCON)  and  electronic  support  measures  (ESM) 

•  Subsystem  status  monitoring 

The  RFC  will  generate  time-tagged  commands  to  the  aperture  subsystem,  RF/IF  subsystem,  and 
other  DSP  subsystem  components  to  effect  these  low-level  operations. 

The  high-level  radar  tasks  controlled  by  the  RFC  include  the  following: 

•  Volume  air  surveillance 

•  Florizon  search 

•  Surface  search 

•  Periscope  detection 

•  Queued  search 

•  Air  target  track/discrimination/classification  (NCTR,  non-cooperative  target  recognition) 

•  Surface  target  track/discrimination/classification  (NCTR) 

•  Space  track/discrimination/classification 

•  Passive  surveillance 

•  Passive  track 

•  Bistatic  surveillance 

•  Bistatic  track 

•  Subsystem  status  monitoring 

•  Calibration 

•  BIT 


4. 3.2. 2.2  Communications  Function  Controller  (CFC) 

The  CFC  controls  one  or  more  communication  interfaces.  This  controller  is  implemented  as  a 
software  application  hosted  on  a  general-purpose  processor  (typically  a  microprocessor-based  GPPE). 
The  software  application  will  execute  under  a  real-time,  preferably  open  architecture,  operating  system.  It 
is  responsible  for  higher-level  functionality.  It  receives  commands  from  the  combat  system,  requests 
assets  from  the  RAM,  and  sources  time-stamped  action  commands  to  its  allocated  aperture,  RF/IF,  and 
DSP  subsystems.  It  transmits  processed  results  (status  and  baseband  data)  to  the  combat  system  and 
shipboard  CFC  clients  (users).  In  a  satellite  communication  application,  CFC  will  receive  a  high-level 
command  such  as:  “Establish  Link:  Satellite  ID,  Full/Half  Duplex,  Baseband  Port  #,  Port  Bandwidth.” 
The  low-level  communication  functions  supportable  by  the  CFC  include  the  following: 
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•  Satellite  ephemeris  calculation 

•  Antenna  pointing/aperture  selection 

•  Face  combining  control 

•  Beam  shape  control 

•  Baseband  port  switching 

•  Channel  multiplexing/demultiplexing 

•  Channel  transcoding 

•  COMSEC  (communications  security  )/TRANSEC  (transmission  security)  control 

•  Link  establishment 

•  Downlink  acquisition 

•  Enable  link  demodulation 

•  Uplink  probing/acquisition 

•  Enable  link  modulation 

•  Link  quality  monitoring/control 

•  Subsystem  status  monitoring 

•  EMCON  and  ESM  control 


The  CFC  will  generate  time-tagged  commands  to  the  aperture  subsystem,  RF/IF  subsystem,  and  DSP 
subsystem  to  effect  these  low-level  operations. 

The  high-level  communication  tasks  controlled  by  the  CFC  include  the  following: 

•  Establish  AEHF  SATCOM,  LDR  uplink/downlink  [M1LSTAR/AEHF/IPS,  Q,  Ka] 

•  Establish  AEHF  SATCOM,  MDR  uplink/downlink  [MILSTAR/AEHF/IPS,  Q,  Ka] 

•  Establish  AEHF  SATCOM,  XDR  uplink/downlink  [MILSTAR/AEHF/IPS,  Q,  Ka] 

•  Establish  CBSP  SATCOM,  uplink/downlink  [Commercial  X,  Ku,  Ka] 

•  Establish  WGS  SATCOM,  uplink/downlink  [Military  X,  Ka] 

•  Establish  GBS  SATCOM,  downlink  [Military,  Ka] 

•  Establish  DTV  SATCOM,  downlink  [Commercial,  Ku] 

•  Establish  LOS  CDL-N  uplink/downlink  [Military,  X,  Ku] 

•  Subsystem  status  monitoring 

•  Calibration 

•  BIT 


4. 3.2. 2. 3  EW  Function  Controller  (EFC) 

The  EFC  is  responsible  for  controlling  one  or  more  EW/IO  missions.  This  controller  is  implemented 
as  a  software  application  hosted  on  a  general-purpose  processor  (typically  a  microprocessor-based 
GPPE).  The  software  application  will  execute  under  a  real-time,  preferably  open  architecture,  operating 
system.  It  is  responsible  for  higher-level  functionality.  It  receives  commands  from  the  combat  system, 
requests  assets  from  the  RAM,  and  sources  time-stamped  action  commands  to  its  allocated  aperture, 
RF/IF,  and  DSP  subsystems.  It  transmits  processed  results  (status  and  target  data)  to  the  combat  system.  It 
will  negotiate  with  the  RAM  for  processing  resources  necessary  to  complete  its  mission  as  assigned  by 
the  combat  system. 

The  EFC  utilizes  the  RF/IF  converters  as  input  devices  for  the  EW/IO  receive  function  and  the  IF/RF 
converters  as  output  devices  for  the  EA  transmit  function.  The  EW/IO  function  consists  of  five  modes  of 
operation: 
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•  High  gain  high  sensitivity  (HGHS)  to  search  for  low-power  radar  and  communications 
signals; 

•  High  probability  of  intercept  (HPOI)  to  perform  searches  for  new  signal  activity  (radar 
and  communications); 

•  Precision  direction  finding  (PDF)  to  perform  angle-of-arrival  measurements  on  signal 
activity  found  by  the  HPOI  function; 

•  Specific  emitter  identification  (SEI)  subsystem  to  identify  and  catalogue  specific 
emitters/platforms;  and 

•  Electronic  attack  (EA). 


The  EFC  may  dynamically  re-allocate  resources  between  these  functions  to  optimize  the  use  of 
resources  throughout  a  threat  engagement  scenario.  It  also  controls  the  real-time  signal  data  linkage 
between  the  receiver  and  exciter  (IF/RF)  components  to  implement  the  digital  RF  memory  and  other 
technique  generators  for  electronic  attack,  both  of  which  require  tight  coupling  with  the  EW  receiver 
resources. 

The  low-level  EW  functions  supportable  by  the  EFC  include  the  following: 

•  New  signal  detection 

•  Parameter  measurement 

•  PRI  (pulse  repetition  interval)  analysis 

•  Rapid  response 

•  AoA  (angle  of  arrival)  determination 

•  De-interleaving 

•  Parameter  derivation 

•  Scan  analysis 

•  EA  technique  generation  and  DRFM 

•  Threat  signal  snapshot 


The  EFC  will  generate  time-tagged  commands  to  the  aperture  subsystem,  RF/IF  subsystem,  and 
other  DSP  subsystem  elements  to  effect  these  low-level  operations. 

The  high-level  EW  tasks  controlled  by  the  EFC  include  the  following: 

•  Correlation/classification 

•  Tracking 

•  Environmental  monitoring  (interference)  and  mitigation 

•  EMCON 

•  SEI 

•  HGHS 

•  Electronic  countermeasures 

•  Electronic  attack 

•  Subsystem  status  monitoring 

•  Calibration 

•  BIT 
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4.3.3  Interfaces 

This  section  describes  the  interfaces  the  DSP  subsystem  has  with  the  rest  of  the  system.  These 
interfaces  are  divided  into  two  main  categories:  digital  and  infrastructure.  The  digital  interface  sections 
describe  the  data,  control,  and  status  messages  that  pass  between  system  components.  The  infrastructure 
interface  section  describes  the  mechanical,  power,  and  cooling  philosophy  for  the  DSP. 


4.3.3. 1  Digital  Interfaces 

The  DSP  subsystem  shall  have  external  digital  interfaces  to  other  InTop  subsystem  components  and 
shall  have  internal  interfaces  between  its  own  components.  DSP  subsystem  external  interfaces  consist  of 
the  interfaces  to  the  aperture,  RF/IF,  and  RAM/SW/CS  subsystems.  The  SPPE  elements  may  include 
additional  dedicated  interfaces  unique  to  their  functionality. 

4.3.3. 1 . 1  Aperture-DSP  Interface 

The  aperture-DSP  subsystem  interface  consists  entirely  of  digital  messages  used  to  transfer  context 
information  between  the  aperture  subsystem  and  the  DSP  subsystem,  and  between  the  aperture  subsystem 
and  the  function  controllers.  Functionality  includes  error  and  status  reporting,  beam  steering  commands, 
and  aperture  inertial  navigation  system  (INS)  information. 

This  interface  shall  be  effected  using  Ethernet  protocol  with  a  minimum  interconnect  data  rate  of  1 
Gbit/s.  All  messages  shall  carry  a  time  tag  which  indicates  time  of  measurement  or  time  of  action  as 
appropriate.  Ethernet  packets  shall  include  VRT  (VITA-49)  header  information  associated  with  VRT 
“Context”  packets.  Required  time  synchronization  will  be  the  individual  responsibility  of  the  aperture  and 
DSP  subsystems. 

Aperture-DSP  subsystem  interfaces  shall  be  full  duplex  links  using  User  Datagram  Protocol/Internet 
Protocol  (UDP/IP)  or  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP).  Each  aperture  shall  be 
on  an  independent  subnet  so  as  to  isolate  the  collision  domains. 

4.3.3. 1.2  RF/IF-DSP  Interface 

The  RF/IF-DSP  subsystem  interface  consists  entirely  of  digital  messages  (packetized)  used  to 
transfer  both  context  information  and  digitized  RF  and  IF  signal  information  between  the  RF/IF 
subsystem  and  the  DSP  subsystem.  The  context  and  signal  interfaces  may  be  implemented  as  independent 
interfaces  or  may  be  merged  onto  a  common  link.  All  messages  shall  carry  a  time  tag  which  indicates 
time  of  measurement  or  time  of  action  as  appropriate.  Packets  shall  include  VRT  (VITA-49)  packet 
constructs  associated  with  VRT  “IF  Data  Packet”  or  “IF  Context  Packets.”  The  “IF  Data  Packet” 
construct  will  also  be  used  in  the  transmit  direction  to  transfer  digitized  waveform  data  from  the  DSP 
subsystem  to  digital-to-analog  converters  within  the  RF/IF  subsystem. 

Context  packets  may  be  transferred  between  the  RF/IF  subsystem  and  both  the  DSP  subsystem  and 
function  controllers.  IF  data  packets  shall  only  be  transferred  between  the  RF/IF  subsystem  and  the  DSP 
subsystem. 

This  interface  shall  be  effected  using  the  Ethernet  or  Infmiband  (IB)  protocols  with  a  minimum 
interconnect  data  rate  of  1  Gbit/s  for  context  packets  and  10  Gbit/s  for  IF  data  packets.  All  links  shall  be 
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full  duplex  using  UDP/IP  or  IB  User  Datagram  Protocols.7  All  links  shall  be  layer  2  routable.  Link 
collision  domains  shall  be  isolated  to  the  extent  practicable. 

Required  time  synchronization  will  be  the  individual  responsibility  of  the  RF/IF  and  DSP 
subsystems. 

4.3.3. 1 .3  RAM/S W/C S-D SP  Interface 

The  RAM/SW/CS-DSP  subsystem  interface  consists  of  digital  messages  (packetized)  used  to 
transfer  context  and  timing  information  between  the  RAM/CS  subsystem  and  both  the  DSP  subsystem 
and  the  function  controllers.  The  RAM/SW/CS-DSP  interface  will  optionally  provide  timing  discretes  to 
effect  synchronization  between  the  subsystems. 

The  packetized  interface  shall  be  established  using  the  Ethernet  protocol  with  a  minimum 
interconnect  data  rate  of  1  Gbit/s.  Timing  messages  shall  utilize  Network  Time  Protocol  (NTP)  or 
Precision  Time  Protocol  (PTP)  message  formats.  All  other  packets  shall  carry  a  time  tag  which  indicates 
time  of  measurement  or  time  of  action  as  appropriate.  The  non-timing  Ethernet  packets  shall  include  VRT 
(VITA-49)  header  information  associated  with  VRT  “Context”  packets. 

For  special  applications,  time  synchronization  to  CPE  or  SPE  elements  may  be  effected  using  timing 
discretes  consisting  of  a  10  MHz  sine  wave  reference  clock  and  a  1  PPS  synchronization  pulse  time- 
aligned  to  the  10  MHz  reference.  Alternatively,  an  IRIG-B  (Inter  Range  Instrumentation  Group)  timing 
interface  can  be  provided. 

4.3.3. 1 .4  DSP-Function  Controller  Interface 

The  DSP  subsystem-Function  Controller  interface  is  an  internal  interface  consisting  of  packetized 
digital  messages  used  to  transfer  commands  and  status  (context)  between  the  function  controllers  and  the 
DSP  subsystem  and  to  transfer  processed  results  (data  packets)  between  the  function  controllers  and  the 
DSP  subsystem. 

The  packetized  interface  shall  be  effected  using  the  Ethernet  or  IB  protocol  with  a  minimum 
interconnect  data  rate  of  1  Gbit/s.  Packets  shall  carry  a  time  tag  which  indicates  time  of  measurement  or 
time  of  action  as  appropriate.  Packets  shall  include  VRT  (VITA-49)  header  information  associated  with 
VRT  “Context”  packets  for  command  and  status  information  and  header  information  associated  with 
VRT  “Extended  Data”  packets  for  processed  results. 

4.3.3. 1.5  Internal  DSP  Subsystem  Interfaces 

The  internal  data  interface  between  DSP  subsystem  building  blocks  will  consist  of  packetized  digital 
messages  used  to  transfer  commands  (context)  and  partial  results  between  the  allocated  SPE,  CPE,  and 
GPPE  blocks. 


7  UDP  (sometimes  referred  to  as  “unreliable”  datagram  protocol)  uses  a  simple  transmission  model  without  implicit 
hand-shaking  dialogues  for  guaranteeing  reliability,  ordering,  or  data  integrity,  and  thus  avoids  the  overhead  of  such 
processing  at  the  network  interface  level.  Because  of  this  simple  approach,  UDP  datagrams  may  arrive  out  of  order, 
appear  duplicated,  or  go  missing  without  notice.  UDP  assumes  that  error  checking  and  correction  is  either  not 
necessary  or  is  performed  in  the  application. 
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The  packetized  interface  shall  be  effected  using  the  Ethernet  or  IB  protocol  with  a  minimum 
interconnect  data  rate  of  10  Gbit/s.  Packets  shall  carry  a  time  tag  which  indicates  time  of  measurement, 
generation  or  time  of  action  as  appropriate.  Packets  shall  include  VRT  (VITA-49)  header  information 
associated  with  VRT  “Context”  packets  for  command  and  status  information  and  header  information 
associated  with  VRT  “Extended  Data”  packets  for  partial  results  being  transferred  between  interconnected 
blocks. 


4.3.3.2  Infrastructure  Interfaces 

In  most  applications,  it  is  assumed  that  the  DSP  subsystem  will  be  implemented  in  a  standard  form- 
factor,  such  as  a  6U  VME8  or  VPX9  19-inch  rack-mount  card  cage.  Selection  of  this  standard  form-factor 
will  define  the  power  interface  to,  and  the  cooling  capabilities  of,  the  card  cage,  as  well  as  the  physical 
dimensions  of,  and  electrical  interfaces  to,  cards  that  plug  into  the  card  cage.  The  card  electrical  interfaces 
include  power  supply  voltages,  maximum  power  consumption  for  each  card,  and  the  backplane  connector 
pin  assignments. 

As  defined  earlier  in  this  report,  Ship  Replaceable  Units  are  hardware  components  in  the  system  for 
which  the  government  defines  and  controls  the  interfaces  and  the  functionality  of  replaceable  elements  in 
the  system.  Shop  Replaceable  Assemblies,  on  the  other  hand,  are  replaceable  components  in  the  system 
for  which  the  government  does  not  necessarily  own  and/or  control  the  interfaces  or  the  functionality. 
SRAs  may  be  replaceable  elements  within  SRUs.  In  this  vision  of  the  DSP  subsystem,  a  rack-mounted 
VME  or  VPX  card  cage  could  be  considered  an  SRU,  with  defined  interfaces  and  functionality.  This 
would  allow  an  entire  card  cage  to  be  replaced  as  part  of  a  future  tech  refresh  event,  if  desired.  The  cards 
that  plug  into  this  card  cage  could  be  considered  SRUs  or  SRAs,  at  the  designer’s  discretion  and  customer 
concurrence. 


8  The  VersaModule  Eurocard  (VME)  bus  is  an  industry  open  standard  system  originated  in  1981  and  designed  to  be 
plugged  into  a  backplane  that  has  up  to  21  slots.  A  VMEbus  board  can  be  either  single  or  double  height.  A  single 
height  board  is  100  mm  x  160  mm  with  one  96-pin  DIN  41612  connector  called  PI  on  the  rear  that  plugs  into  the 
backplane.  A  double  height  board  is  233  mm  *  160  mm  and  may  have  a  second  96-pin  DIN  connector  called  P2.  A 
single  height  board  is  also  known  as  a  3U,  and  a  double  height  as  a  6U.  The  front  edge  or  face  of  a  typical  board  is 
20  mm  wide  and  may  incorporate  RS-232  connectors,  indicator  lights,  and  switches. 

9  VITA  developed  improvement  in  the  performance  of  VME  technologies.  VPX  (VITA-46)  specifications 
established  a  new  direction  for  the  next  generation  in  bus  boards.  VPX  breaks  out  from  the  traditional  connector 
scheme  of  VMEbus  to  merge  the  latest  in  connector  and  packaging  technology  with  the  latest  in  bus  and  serial  fabric 
technology.  VPX  combines  new  technologies  to  assure  a  very  long  technology  cycle  similar  to  that  of  the  original 
VMEbus  solutions.  Traditional  parallel  VMEbus  will  continue  to  be  supported  by  VPX. 
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4.4  RAM/SW/CS  Blocks  and  Interfaces 

4.4.1  Resource  Allocation  Oven’iew 

Resource  allocation  in  an  InTop  system  is  the  process  of  assigning  RF  and  digital  resources  to 
multiple  simultaneous  RF  functions.  This  process  works  by  creating  virtual  systems  from  collections  of 
resources.  Any  number  of  virtual  systems  can  exist  at  any  time,  as  long  as  there  are  enough  resources  to 
support  them.  The  resources  of  a  virtual  system  are  “leased”  to  an  RF  function.  Once  a  virtual  system  is 
created,  the  RF  function  “owns”  its  constituent  resources  for  the  duration  of  the  lease.  Figure  4.4-1 
illustrates  the  top-level  architecture  to  support  this  process. 


Fig.  4.4-1  —  Resource  allocation  management  components 


The  central  component  of  this  process  is  the  resource  allocation  manager,  which  operates  in 
conjunction  with  these  other  components: 

•  External  interface  controllers 

•  RF  function  controllers 

•  The  InTop  time  server 

•  Resource  controllers 

•  Internal  diagnostic  displays 
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Figure  4.4-2  illustrates  the  basic  flow  of  execution  of  an  InTop  system.  This  activity  diagram  depicts 
a  typical  request  for  radar  services  from  an  external  combat  system. 

(1)  The  process  begins  with  a  tasking  request  by  the  combat  system. 

(2)  This  request  is  received  by  an  external  interface  controller,  translated  if  needed,  and  presented  to 
the  internal  InTop  network  infrastructure.  The  request  is  then  picked  up  by  a  radar  function  controller. 
This  function  controller  decides  what  types  of  resources  it  will  need  to  create  a  virtual  system  to  perform 
the  requested  task. 

(3)  The  radar  function  controller  then  sends  a  request  for  these  resources  to  the  RAM.  The  RAM 
chooses  a  set  of  resources  that  will  fulfill  the  request,  if  possible. 

(4)  The  RAM  then  sends  an  acknowledgement  of  the  request,  indicating  success  or  failure.  This 
acknowledgement  is  used  by  the  radar  function  controller  to  send  an  appropriate  acknowledgement  to  the 
combat  system. 

(5)  If  the  request  is  successful,  the  RAM  broadcasts  the  resource  assignments  to  all  resource 
controllers. 

(6)  Each  resource  controller  then  prepares  its  relevant  resources  to  participate  in  this  new  virtual 
system. 

(7)  The  resources  are  then  activated  at  the  appropriate  time. 

(8)  Once  activated,  the  virtual  system  is  under  the  control  of  the  radar  function  controller. 
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Fig.  4.4-2  —  Overall  InTop  flow  of  execution 


4. 4. 2  Components  and  Functional  Allocations 

The  resource  allocation  components  identified  above  are  primarily  software  components. 
Components  such  as  the  resource  allocation  manager  and  RF  function  controllers  probably  do  not  need  to 
be  tied  to  any  particular  piece  of  hardware  and  can  be  hosted  by  general-purpose  processors  within  the 
DSP  subsystem  and  can  be  moved  between  processors  as  needed.  This  section  describes  each  of  the 
components  in  greater  detail. 
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4.4.2.1  External  Interface  Controller  Subsystem  (EICS) 

External  interface  controllers  are  responsible  for  interfacing  an  InTop  system  to  other  ship  systems. 
The  other  ship  systems  are  anticipated  to  be  primarily  combat  systems  and  communications  infrastructure. 
The  external  interface  controller  subsystem  (EICS)  provides  adaptation  of  the  internal  InTop  interfaces  to 
these  external  systems.  A  primary  feature  of  the  EICS  is  to  emulate  the  legacy  equipment  that  InTop 
replaces  so  that  the  specific  interfaces  from  InTop  to  other  existing  ship  systems  remain  unchanged.  That 
is,  the  replacement  of  legacy  RF  equipment  by  an  InTop  system  would  ideally  be  transparent  to  other 
existing  ship  systems. 

4.4.2.2  RF  Function  Controllers 

An  RF  function  controller  “owns”  the  knowledge  of  how  to  implement  one  or  more  RF  functions 
within  the  InTop  system.  It  receives  tasking  from  the  combat  system,  translates  this  tasking  into  a  set  of 
resource  requirements,  and  makes  appropriate  requests  to  the  resource  allocation  manager.  Once  the 
controller  has  acquired  a  lease  to  a  set  of  appropriate  resources,  it  takes  control  of  the  resulting  virtual 
system  to  carry  out  its  tasking.  It  will  monitor  the  execution  of  its  given  tasks  and  make  adjustments  as 
necessary. 

4.4.2.3  Resource  Allocation  Manager  (RAM) 

The  RAM  is  responsible  for  the  dynamic  allocation  of  resources  resident  in  the  InTop  system.  It 
keeps  track  of  the  availability  of  resources  by  monitoring  built-in-test  reports  provided  by  resource 
controllers.  The  RAM  performs  allocations  based  on  requests  from  RF  function  controllers  and  based  on 
an  overall  system  priority  doctrine.  The  RAM  will  evaluate  these  requests  and  assign  resources  based  on 
the  current  utilization  and  request  priority.  Each  request  will  also  be  evaluated  based  on  frequency  and 
radiated  power  plans.  If  the  resources  are  available,  the  RAM  provides  a  lease  to  these  resources,  thus 
creating  a  virtual  system  that  can  be  controlled  by  the  requesting  RF  function  controller.  Multiple  virtual 
systems  can  be  established  simultaneously  as  long  as  the  resources  are  available  to  support  them. 

4.4.2.4  Resource  Controllers 

A  resource  controller  will  control  one  or  more  allocatable  resources.  A  resource  controller  provides  a 
standard  set  of  interfaces  to  the  InTop  system.  It  translates  these  interfaces  to  and  from  resource-specific 
interfaces.  A  resource  controller  will  advertise  the  capabilities  of  the  allocatable  resources  under  its 
control.  It  will  perform  setup  of  its  resources  for  new  allocations  and  activate  the  resources  at  the 
appropriate  time.  It  is  responsible  for  translating  InTop  standard  control  messages  into  resource-specific 
control  signals  and  messages.  It  is  also  responsible  for  performing  built-in-test  and  providing  status  of  its 
resources. 

4.4.2. 5  Time  Server 

The  time  server  is  responsible  for  distributing  time  of  day  to  all  subsystems  within  InTop.  The  InTop 
time  server  can  be  synchronized  to  an  external  source  such  as  the  ship’s  time  service,  GPS,  IRIG,  etc.  If 
an  external  source  is  not  available  or  is  interrupted,  the  time  server  will  “flywheel”  and  keep  time  on  its 
own.  Time  can  be  provided  in  a  variety  of  formats  to  accommodate  various  hardware  and  software  users. 
One  such  format  may  be  the  Network  Time  Protocol  over  the  internal  IP  network,  which  is  suitable  for 
synchronizing  operating  system  clocks  to  accuracy  on  the  order  of  a  millisecond.  A  10  MEIz  reference 
clock  will  be  distributed  to  all  InTop  subsystems.  This  reference  clock  will  be  used  to  synthesize  all 
timing  throughout  the  InTop  system.  Any  precision  time  formats,  such  as  a  1  PPS  trigger  or  IRIG-B 
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DCLS  (Direct  Current  Level  Shift  modulated  IRIG-B)  coded  time  standard,  will  be  synchronized  with 
this  reference. 

4.4.2.6  Internal  Diagnostic  Displays 

The  internal  diagnostic  displays  will  provide  operator  control  of  InTop  via  a  graphical  user  interface 
(GUI).  The  GUI  is  intended  to  enable  stand-alone  operation  of  InTop  for  diagnostic  or  maintenance 
purposes.  The  primary  control  of  InTop  is  expected  to  be  from  outside  of  InTop,  such  as  from  combat 
and/or  communication  systems.  It  should  be  possible  to  use  this  GUI  either  internally  or  from  an  external 
location. 

4.4.3  Interfaces 

One  of  the  goals  for  InTop  is  to  eliminate  the  need  for  unique  special-purpose  interfaces  between  its 
various  subsystems.  These  interfaces  will  be  replaced  by  a  small  set  of  standard  physical  interfaces  to 
standard  InTop  time  and  network  services. 

4.4.3.1  Time  Service  Interfaces 

InTop  control  and  resource  allocation  is  based  on  the  time  of  day.  It  is  expected  that  each  subsystem 
can  synthesize  its  own  timing  based  on  the  time  of  day.  This  requires  that  all  subsystem  clocks  be 
synchronized  with  each  other.  To  accommodate  this  requirement,  a  common  InTop  time  service  will 
provide  the  following  services: 

•  A  1 0  MHz  reference  clock 

•  Precision  time-of-day  (TOD)  service 

•  Network  time  service 

4. 4. 3. 1.1  1 0  MHz  Reference  Clock 

A  master  10  MHz  reference  clock  will  be  provided  to  all  subsystems.  All  other  clocks  and  timing 
throughout  the  InTop  system  will  be  derived  from  this  single  source.  The  stability  of  this  clock  will  be 
determined  from  the  worst-case  requirements  of  the  supported  RF  functions. 

4.4.3. 1.2  Precision  Time-of-Day  Service 

One  or  more  precision  time-of-day  services  will  be  distributed  to  all  subsystems.  Candidate  formats 
include  a  1  PPS  strobe  and  IRIG-B  DCLS. 

The  simplest  format  for  this  service  would  be  a  1  PPS  timing  strobe  in  combination  with  a  network 
time  service.  The  1  PPS  strobe  would  be  synchronized  with  the  10  MHz  reference,  such  that  each  1  PPS 
strobe  indicates  the  precise  clock  transition  corresponding  to  each  new  second  of  the  time  of  day.  The  full 
date  and  time  of  day  would  be  known  based  on  a  separate  network  time  service. 

A  more  self-contained  format  would  be  IRIG-B  DCLS.  The  IRIG-B  DCLS  signal  will  provide  date 
and  time  of  day  without  the  need  for  a  separate  network  time  service.  The  IRIG-B  DCLS  signal  would 
also  need  to  be  synchronized  with  the  10  MHz  reference. 
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4.4.3. 1.3  Network  Time  Service 

A  network  time  service  can  be  used  where  less  precision  is  required  or  to  augment  a  1  PPS  precision 
timing  strobe.  Candidate  services  include  Network  Time  Protocol/Intemet  Engineering  Task  Force  (IETF) 
(RFC-1305)  or  Precision  Time  Protocol  (PTP  /  IEEE-1588). 

4.4.3.2  Network  Services 

All  InTop  subsystems  will  be  interconnected  by  a  network  infrastructure  such  as  10  Gigabit  Ethernet. 
Whatever  physical  network  infrastructure  is  used,  all  communications  will  be  based  on  the  Internet 
Protocol  suite  (commonly  known  as  TCP/IP)  which  includes  TCP  and  UDP. 

4. 4. 3. 2.1  Publish/Subscribe  Messaging  Methodology 

Most  InTop  network  message  traffic  between  subsystems  shall  use  a  publish/subscribe  methodology. 
With  publish/subscribe  (pub/sub),  programs  desiring  to  receive  a  message  of  a  certain  type  will 
“subscribe”  for  that  message.  Once  a  program  subscribes  to  a  message,  the  program  shall  subsequently 
receive  all  messages  of  that  type  regardless  of  who  the  sender  is.  Sending  programs,  on  the  other  hand, 
merely  send  or  “publish”  messages  “into  the  ether.”  Sending  programs  shall  not  know  or  be  concerned 
with  what  programs  have  registered  to  receive  the  messages  they  publish. 

Using  the  publish/subscribe  methodology  allows  programs  to  be  developed  more  openly  and 
generically,  thus  preserving  the  investment  in  the  software  over  time.  The  bookkeeping  required  to 
implement  the  publish/subscribe  methodology  will  be  provided  in  a  separate  layer  below  the  application 
programs  such  as  Object  Management  Group’s  Data-Distribution  Service  (DDS)  middleware. 

4. 4. 3. 2.2  Low-Latency  Reactive  Control 

Resource  allocation  and  control  messaging  is  built  on  top  of  this  publish/subscribe  infrastructure 
which  is  built  on  top  of  the  Internet  Protocol  suite.  In  order  to  accommodate  the  latency  inherent  to  this 
protocol  stack,  messages  must  be  sent  sufficiently  in  advance  to  account  for  the  worst-case  latency 
expected.  The  latencies  involved  will  depend  on  a  variety  of  factors  including  the  capabilities  of  the 
processing  hardware  and  network  infrastructure  chosen,  operating  systems,  software,  and  competition  for 
CPU  and  network  resources.  The  worst-case  latency  may  be  on  the  order  of  milliseconds.  This  is  probably 
not  sufficient  for  the  reactive  types  of  control  needed  to  support  EW  functions. 

EW  functions  cannot  necessarily  plan  ahead  and  must  react  quickly  to  external  RF  events  in  the 
environment.  In  order  to  accommodate  this  requirement,  a  low-latency  control  path  between  subsystems 
must  be  provided.  End-points  in  this  infrastructure  may  be  implemented  as  either  software  or  hardware. 
This  type  of  infrastructure  is  typically  accomplished  using  a  dedicated  real-time  control  network  or  other 
specialized  interfaces  between  subsystems. 

Rather  than  introducing  a  dedicated  real-time  control  network,  it  may  be  possible  to  use  the  same 
network  infrastructure  by  interfacing  to  it  at  a  lower  level.  Control  messages  can  be  sent  by  using  User 
Datagram  Protocol.  UDP  is  very  simple  and  requires  no  complex  flow  control  between  participants, 
which  makes  it  ideal  for  hardware  implementations.  A  UDP  packet  sent  via  Ethernet  using  IPv6  (Internet 
Protocol  version  6),  requires  66  bytes  of  overhead  for  the  Ethernet,  IP  and  UDP  envelope  information.  A 
4  byte  message  would  therefore  require  a  70  byte  packet.  The  transmission  time  for  this  70  byte  packet  on 
a  single  segment  of  a  10  Gbps  Ethernet  would  be  56  nanoseconds.  The  total  latency  will  depend  on  the 
topology  of  the  network.  It  should  be  possible  to  arrange  the  network  switching  infrastructure  such  that  a 
dedicated  path  exists  between  critical  real-time  components  while  still  allowing  any  component  to 
participate. 
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In  order  to  keep  latency  to  a  minimum,  it  is  envisioned  that  messages  over  this  real-time  control 
infrastructure  will  be  small,  consisting  primarily  of  indexes  into  pre-loaded  information  (e.g.,  frequency 
indexes,  receiver  configurations,  etc.).  This  mechanism  can  also  be  used  to  activate  high-priority  resource 
allocations.  In  this  case  the  high-priority  allocations  can  be  pre-loaded  by  the  resource  allocation  manager 
into  a  set  of  standby  configurations  of  the  InTop  resources.  A  message  over  this  real-time  infrastructure 
would  be  used  to  quickly  activate  the  desired  allocation,  interrupting  the  current  lower-priority  allocation. 

4. 4. 3. 2. 3  Isolation  of  Red/Black  Information 

An  InTop  system  may  combine  several  disparate  RF  functions.  This  combination  of  functions  may 
necessitate  support  for  multiple  levels  of  classification  —  Red/Black  —  within  the  same  system.  While 
most  communications  links  will  be  encrypted  end-to-end,  the  classification  of  out-of-band  control 
information  and  other  processing  must  also  be  considered.  Even  if  it  is  determined  that  communications 
control  and  other  processing  can  be  co-mingled  at  a  common  classification  level,  support  for  unencrypted 
channels  such  as  commercial  television  is  problematic.  These  issues  must  be  considered  carefully 
throughout  the  design  process  of  a  tactical  InTop  system. 

4. 4. 3. 2.4  Network  Interface  Domains 

The  multitude  of  digital  messages  carried  over  the  InTop  network  infrastructure  can  be  classified  by 
the  following  top-level  interfaces: 

•  Application  control  interface 

•  Function  control  interface 

•  Resource  request  interface 

•  Resource  allocation  interface 

•  Resource  control  interface 

•  Co-site  EMI  mitigation  interface 

•  Application  data  interface 


4.4. 3. 2.4.1  Application  Control  Interface  —  The  application  control  interface  consists  entirely  of 
digital  messages  used  to  control  software  applications  within  the  InTop  system.  Example  functionality 
includes  error  and  status  reporting,  state  control  of  applications  and  their  associated  subsystems,  and 
producing  and  monitoring  heartbeats. 

4.4. 3. 2.4. 2  Function  Control  Interface  —  The  function  control  interface  consists  entirely  of 
digital  messages  used  between  the  external  interface  controller  subsystem  and  the  InTop  function 
controllers.  The  purpose  of  this  interface  is  to  convey  requests  from  the  combat  system  or  other  external 
users  via  the  external  interface  controller.  This  interface  would  also  include  messages  to  convey  status 
and  capabilities  of  the  RF  functions  to  the  combat  system  and  other  external  users. 

This  interface  domain  must  accommodate  messages  which  are  specific  to  each  RF  function  and  be 
extensible  in  order  to  easily  accommodate  new  functions  and  capabilities  as  they  are  introduced  over  the 
lifetime  of  an  InTop  system. 

4.4. 3. 2.4. 3  Resource  Request  Interface  —  The  resource  request  interface  domain  consists  entirely 
of  digital  messages  involved  in  the  process  of  requesting  the  allocation  of  resources  from  the  InTop 
RAM.  These  messages  include  the  availability  of  allocatable  resources,  resource  allocation  requests,  and 
their  status. 
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4.4. 3. 2.4.4  Resource  Allocation  Interface  —  The  resource  allocation  interface  consists  entirely  of 
digital  messages  between  the  InTop  RAM  and  the  various  resource  controllers.  This  interface  will  provide 
the  resource  controllers  a  mechanism  to  report  the  capabilities,  status,  and  availability  of  their  allocatable 
resources.  The  InTop  RAM  will  use  this  interface  to  describe  new  resource  allocations  or  “virtual 
systems”  so  that  various  resource  controllers  can  set  up  their  relevant  allocatable  resources  at  the 
appropriate  time. 

4.4. 3. 2.4. 5  Resource  Control  Interface  —  The  resource  control  interface  consists  entirely  of 
digital  messages  that  are  used  by  InTop  functions  to  control  InTop  allocatable  resources  once  the 
resources  have  been  allocated  to  the  function.  These  messages  would  typically  originate  from  function 
controllers;  however,  they  may  originate  from  any  software  component  currently  belonging  to  the 
appropriate  function. 

4.4. 3. 2.4. 6  Application  Data  Interface  —  The  application  data  interface  consists  of  various  data 
messages  between  digital  components  that  comprise  a  virtual  system.  These  messages  would  include 
voice,  video,  detections,  tracks,  and  other  data  products  produced  or  consumed  by  a  virtual  RF  system. 

This  interface  domain  must  accommodate  messages  which  are  specific  to  each  RF  function  and  be 
extensible  in  order  to  easily  accommodate  new  functions  and  capabilities  as  they  are  introduced  over  the 
lifetime  of  an  InTop  system. 

4.4. 3. 2.4. 7  Additional  Interfaces  —  Additional  interfaces  and/or  messages  relative  to  any  of  the 
subsystems  beyond  those  described  in  this  report  may  also  be  necessary.  For  example,  additional 
interfaces  could  include  Network  File  System  (NFS)  for  sharing  common  disk  drives;  and  remote  login 
services  such  as  Secure  Shell  (SSH)  to  facilitate  installation  and  maintenance  of  InTop  hardware  and 
software. 
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5.  LEGACY  COMPATIBILITY 

Looking  at  legacy  systems  to  see  where  they  might  interface  with  an  InTop  system  of  systems 
architecture  is  useful  to  gain  insight  into  potential  reuse  of  existing  system  components  while  still 
working  to  achieve  the  tenets  of  InTop  —  a  reduced  topside  footprint  and  integrated  resource 
management  in  a  modular,  open  architecture. 

Many  of  the  legacy  military  electronic  systems  have  unique  interfaces  that  were  established  as 
subsystems  evolved  over  time.  These  include,  for  example,  Link- 16,  Multifunction  Information 
Distribution  System  (MIDS),  Link-11,  and  Cooperative  Engagement  Capability  (CEC)  configurations. 
Historically,  translators  have  been  developed  that  interface  to  the  subsystem’s  unique  input/output 
requirements  and  transform  these  to  industry  open  standards  or  other  subsystem-unique  interfaces  when 
necessary. 

This  section  briefly  examines  the  open  architecture  concepts  of  InTop  as  they  relate  to  active  legacy 
systems. 

5.1  Weapon  Systems  Interfaces 

Weapon  systems  interfaces  are  designed  to  provide  a  high  degree  of  reliability  and  source 
information  assurance  to  prevent  inadvertent  weapon  arming  or  release.  Each  of  the  existing  weapon 
system  interfaces  have  gone  through  extensive  testing  and  very  specific  certification.  InTop  systems  that 
interface  with  these  weapons  systems  must  provide  the  same  level  of  reliability  and  source  data  assurance. 

5.2  Sensor  Systems  Interfaces 

Sensor  systems  interfaces  focus  on  data  time  tagging,  synchronization,  and  correlation  of  position  in 
space.  An  important  factor  is  the  establishment  of  a  Common  Operating  Picture  (COP)  that  includes  the 
minimization  of  duplicate  targets  and  missed  targets.  The  design  of  an  InTop  system  interfacing  with 
sensor  systems  must  take  into  consideration  time  accuracy,  location  accuracy,  and  rapid  or  timely 
information  distribution. 

5.3  Combat  Information  Center  (CIC)  Interfaces 

Combat  information  systems  are  classically  interfaced  through  network  structures  that  also 
emphasize  data  assurance  and  point-to-point  instruction  package  transport.  Security  and  TEMPEST  also 
play  a  significant  role  in  the  traffic  management.  Any  InTop  interface  to  the  distribution  point  of  data 
from  or  to  the  combat  information  center  (CIC)  must  prevent  transmission  to  unauthorized  locations  and 
persons. 

5.4  Radio  Room  and  Communication  Interfaces 

Primary  considerations  for  communication  within  and  between  platforms  are  encryption  and 
information  assurance.  These  factors  are  often  categorized  as  TRANSEC  (transmission  security)  and 
COMSEC  (communication  security),  and  must  be  addressed  on  both  the  user  and  RF  radiating  sides  of 
any  communications  interface.  Additional  evaluation  is  needed  to  clearly  understand  the  number  of 
communications  circuits  needed  to  execute  the  likely  scenarios  that  the  next-generation  platforms  will 
encounter.  This  assessment  is  usually  accomplished  in  an  Information  Exchange  Requirements  (IER) 
study  based  on  mission  definitions  in  a  Concept  of  Operations  (CONOPS)  document. 
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5.5  Multifunction  Compatibility 

InTop  will  provide  both  the  source  and  channel  coding  options  in  an  integrated  set  of  hardware  for 
radar,  active  and  passive  EW,  and  communications  (SATCOM  and  Tactical  LOS).  The  InTop  RAM  will 
leverage  the  application  of  rapidly  reprogrammable  digital  processing  hardware  in  order  to 
simultaneously  transmit  from  a  common  antenna,  and/or  dynamically  schedule  time  domain  management. 
In  order  to  maximize  the  rapid  programmability  of  the  evolving  InTop  antenna/electronics  architecture, 
fewer  hardware-specific  solutions  are  being  considered  and  more  software-managed  functions  (i.e., 
waveforms)  will  be  incorporated  into  common  hardware  suites.  Existing  (legacy)  hardware/software 
systems  may  be  retained,  however,  in  order  to  minimize  the  total  cost.  The  following  sections  identify 
some  of  the  issues  of  legacy  compatibility  with  InTop. 

5.5.1  Waveforms 

A  significant  consideration  in  legacy  compatibility  is  the  need  to  work  with  the  existing  electronic 
hardware  and  software  in  the  processing  environment.  The  architectural  emphasis  is  not  on  just 
assembling  a  programmable  environment,  but  in  doing  so  such  that  legacy  waveforms  do  not  have  to  be 
re-coded  as  InTop  evolves.  This  is  commonly  called  “software  transportability.”  An  example  of  the 
complexity  associated  with  transportable  software  and  the  physical  processing  environment  is  the  Joint 
Tactical  Radio  System  (JTRS).  JTRS  waveforms  may  be  time  multiplexed,  frequency  multiplexed,  or 
deterministic  in  time.  This  complexity  is  significant  in  resource  planning  and  resource  utility,  and  must  be 
accounted  for  in  future  InTop  system  integration/implementation. 

Other  considerations  include  the  establishment  of  “link  priority”  and  the  implementation  of  rapid 
circuit  reconfiguration.  Communication  circuits  are  highly  dependent  upon  the  use  of  situation  awareness 
(SA)  and  combat  identification  (Cl)  inputs  to  provide  the  critical  data  needed  for  establishing  and 
breaking  interfaces,  assigning  priorities,  and  selecting/creating  an  appropriate  waveform.  Deviating  from 
the  use  of  legacy  communications  waveforms  is  a  considerable  undertaking  and  needs  to  be  carefully 
examined  on  a  case-by-case  basis  to  understand  the  associated  cost  and  risk. 

5.5.2  Hardware  and  Systems 

Several  critical  systems  now  in  the  Navy  inventory  may  be  impacted  by  InTop.  The  following 
selected  sample  of  systems  is  discussed  below  to  identify  interface  issues  that  InTop  must  address:  Navy 
Multiband  Terminal  (NMT),  Multifunction  Electronic  Warfare  (MFEW)/SLQ-32  BL2,  UHF  SATCOM, 
Close-In  Weapon  System  (CIWS),  Hawklink  Common  Data  Link  (CDL),  Emissions  Control  (EMCON), 
and  Cooperative  Engagement  Capability  (CEC).  Additional  work  will  be  needed  in  the  development  of 
InTop  to  merge  these  existing  systems  into  an  evolving  architecture  for  both  surface  and  submarine 
platforms.  This  section  is  not  intended  to  be  an  exhaustive  coverage  of  legacy/current  assets  and  how  they 
might  integrate  with  an  InTop  open  architecture,  but  rather  to  (a)  point  out  the  need  for  more  assessment 
in  the  next  phase  of  the  InTop  program,  and  (b)  delineate  some  of  the  considerations  and  the  remaining 
design  trades  to  be  done  as  part  of  the  InTop  development.  An  in-depth  examination  of  InTop  and  legacy 
interfaces,  including  information  operations  and  radar,  will  be  addressed  in  follow-on  architecture  efforts. 

5.5.2.1  Navy  Multiband  Terminal  (NMT)  and  InTop 

The  NMT  program  integrates  the  Navy  high-frequency  SATCOM  functions  into  a  single 
architecture/terminal.  The  baseline  capability  is  viewed  as  a  “2  RF  head  design.”  This  2  RF  head  design 
was  chosen  to  achieve  assured  communications.  The  NMT  program  and  hardware  is  a  complete  system 
from  antenna  and  radome  to  the  user  interface.  Much  design  and  integration  effort  has  gone  into  its 
current  implementation.  When  NMT  is  examined  against  the  InTop  goal  of  reducing  antennas  on  the 
decks  of  future  and  current  ships,  there  seems  to  be  a  logical  break  point  in  the  NMT  package  below  the 
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antenna  RF/IF  section.  Keeping  the  NMT  processing  and  host  platform  interface  represents  significant 
reuse  of  the  existing  NMT  assets,  and  if  InTop  provides  the  antenna  and  transmitter,  establishes  a  balance 
between  preserving  investment  and  reducing  antenna  count  on  the  topside. 

5.5.2.2  Multifunction  Electronic  Warfare  (MFEW)/SLQ-32  BL2  and  InTop 

The  MFEW  architecture  and  design  was  recently  (2005-2008)  developed  as  an  Advanced 
Development  Model  (ADM).  The  MFEW  technology  is  now  transitioning  to  Block  2  of  the  AN/SLQ-32 
Surface  EW  Improvement  Program  (SEWIP).  As  such,  it  will  initially  be  a  stand-alone  passive  system.  A 
subsequent  active  EA  capability  is  now  planned  for  development  as  part  of  InTop.  SEWIP  Block  2  will 
include  the  ability  to  interface  with  the  InTop  EA  function,  and  respond  to  the  InTop  resource  allocation 
manager. 


5.5.2.3  UHF  SATCOM  and  Tactical  LOS  Links  and  InTop 

Currently  the  platform-based  UHF  SATCOM  systems  include  everything  from  the  antenna  to  the 
user  interface.  Transmit  and  receive  are  directed  to/ffom  a  geostationary  satellite,  which  makes  the  beam 
pointing  very  predictable  and  simplifies  the  integration  of  UHF  SATCOM  with  InTop.  The  UHF 
SATCOM  modem  is  also  easy  to  segregate  from  the  transmit  and  receive  RF  components.  The 
partitioning  of  UHF  SATCOM  to  integrate  with  InTop,  and  satisfying  the  topside  size,  weight,  and  power 
reduction,  therefore  appear  to  be  straightforward  and  low  risk. 

UHF  SATCOM  waveforms  have  been  selected  for  the  JTRS  AMF  (airborne  and  maritime-fixed) 
cluster  and  will  likely  be  a  significant  feature  of  the  modem  for  InTop.  In  addition,  with  a  software- 
programmable  electronics  package,  JTRS  can  be  expected  to  easily  integrate  with  the  projected  InTop 
architecture.  Initially  InTop  would  access  the  IF  section  (baseband  -  source  coding  section)  of  the  JTRS 
to  maximize  the  use  of  digital  processing  in  the  area  of  digital  pre-distortion  and  beamforming. 

UHF  Tactical  LOS  links  also  account  for  a  significant  number  of  antennas  on  a  typical  Navy  ship 
and  many  submarines.  Applications  of  narrower  UHF  directed  beam  communications  also  fit  into  the 
notional  phased  array  strategy  for  InTop.  A  bi-static  UHF  antenna  approach  is  a  possible  solution  that 
could  serve  both  SATCOM  and  Tactical  LOS  from  the  same  antennas. 

5.5.2.4  Close-In  Weapon  System  (CIWS)  and  InTop 

The  CIWS  is  a  self-protection,  rapid-fire,  20-millimeter  gun  system  with  a  fully  integrated  Ku-band 
search  and  tracking  radar  sensor.  It  is  a  self-contained,  deck-mounted  unit  with  a  rapid-response 
requirement  between  the  identification,  track,  and  response  to  an  incoming  threat,  and  requires  dedicated 
tracking  during  the  engagement  phase.  The  “timing”  of  the  response  and  the  integral  RF  and  optical 
tracking,  therefore,  make  it  an  unlikely  candidate  for  InTop  integration  and  demonstration  at  this  time. 
However,  future  InTop  integration  efforts  could  include  CIWS  if  so  desired. 

5.5.2.5  LAMPS  Hawklink  (CDL)  and  InTop 

The  Light  Airborne  Multi-Purpose  System  (LAMPS)  Hawklink  is  a  recent  upgrade  to  the  LAMPS 
SH-60  helicopter  system  and  has  a  Ku-band  Tactical  CDL  configuration.  The  ship’s  CDL  has  a  transmit 
and  receive  antenna,  electronic  processing,  and  ship’s  user  interface  components.  It  is  expected  that  the 
InTop  architecture  can  provide  the  RF  services  needed  by  the  CDL  modem. 

Additional  CDL  communications  links  are  also  installed  on  ships  to  communicate  targeting 
information  and  real-time  remote  sensor  data,  and  to  control  remotely  piloted  vehicles.  The  number  of 
these  links  is  platform  dependent  and  expected  to  require  simultaneity.  The  CDL  architecture  has  several 
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frequency  assignments  within  its  500  MHz  transmit  and  receive  allocation.  Coverage  is  hemispherical  and 
would  require  InTop  to  provide  the  same  “visibility”  with  interfaces  similar  to  Hawklink. 

5.5.2.6  Emission  Control  (EMCON) 

EMCON  is  also  an  important  interface  consideration  and  essential  for  legacy  compatibility.  It  is  an 
integral  part  of  the  ship’s  self  defense,  has  real-time  linkage  to  the  management  of  the  RF  signature  of  the 
ship,  and  is  closely  tied  to  the  EW  situation  awareness  and  combat  identification  activities  conducted  on 
the  host  platform.  Notionally  this  would  be  a  command  priority  adaptation  integrated  into  the  InTop 
RAM. 

5.5.2.7  Cooperative  Engagement  Capability  (CEC) 

CEC,  via  a  C-band  LOS  communications  link,  provides  radar  and  target  track  data  throughout  its 
multi-platform  network.  It  has  an  integrated  fire  control  system  that  can  combine  and  distribute  sensor 
data  to  each  element  (member)  of  a  networked  force.  A  future  capability  planned  for  CEC  is  the  updating 
to  Joint  Composite  Tracking  Network  (JCTN).  InTop  may  expect  to  develop  in-band  apertures  to 
incorporate  both  these  current  and  future  functions. 

5.6  Summary  of  Integration  Potential 

Table  5.6-1  provides  a  quick  look  at  the  initial  potential  for  these  legacy  systems  and  InTop  to 
merge.  System  functions  are  identified  at  the  top  of  each  column.  “InTop”  is  used  in  the  table  to  indicate 
where  InTop  will  likely  provide  the  system  function.  The  legacy  system  name  occurs  in  the  table  where 
the  legacy  equipment  would  continue  to  perform  that  function.  This  table  represents  a  preliminary  look  at 
combining  the  InTop  and  legacy  architectures. 


Table  5.6-1  —  Initial  Trade  Space  Considerations  for  Integration  of  Legacy  Systems  and  InTop 


System 

Transmit 

Receive 

Aperture 

Subsystem 

RF/IF 

Subsystem 

DSP 

Subsystem 

RAM/SW/CS 

Subsystem 

NMT 

X 

X 

InTop 

NMT 

NMT 

InTop 

SLQ-32(ES) 

X 

SLQ-32 
Blk.  2 

SLQ-32 
Blk.  2  / 
InTop 

SLQ-32 
Blk.  2  / 
InTop 

InTop 

SLQ-32(EA) 

X 

X 

InTop 

InTop 

InTop 

InTop 

UHF 

SATCOM 

X 

X 

InTop 

InTop 

JTRS 

InTop 

UHF-LOS 

X 

X 

InTop 

InTop 

JTRS 

InTop 

CIWS 

X 

X 

CIWS 

CIWS 

CIWS 

n/a 

CDL  H-L 

X 

X 

InTop 

InTop 

CDL 

InTop 

CDL  Sensor 

X 

X 

InTop 

InTop 

CDL 

InTop 

CEC 

X 

X 

InTop 

CEC 

CEC 

InTop 

EMCON 

X 

InTop 

n/a 

n/a 

InTop 

X  =  Function 
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6.  DESIGN  AND  ACQUISITION  CHALLENGES  AND  RECOMMENDATIONS 

Although  the  InTop  Open  Architecture  Study  deliberately  stopped  short  of  establishing  definitive 
functional  partition  boundaries  and  explicit  open  interface  definitions,  there  was  general  consensus  among 
the  study  participants  on  several  aspects  of  OA  design  and  implementation.  Some  of  these  are  presented 
in  this  section  as  observations  that  may  be  helpful  to  the  Navy  and  industry  as  they  progress  together 
toward  the  objectives  of  the  Integrated  Topside  program.  In  addition,  there  were  some  philosophical 
questions  addressed  for  which  different  perspectives  were  articulated  and  important  trade-offs  were 
considered  and  debated.  Even  though  a  broad  consensus  was  not  reached  on  many  of  these  topics,  it  is 
worthwhile  to  document  some  of  them  so  that  both  the  Navy  and  industry  can  continue  to  consider  their 
implications  and  impacts  as  the  InTop  program  proceeds  toward  the  realization  of  multifunction  RF 
systems  that  are  truly  modular,  scalable,  and  open. 

Finally,  there  was  much  discussion  on  what  the  best  open  systems  acquisition/business  model  might 
be  to  support  the  development,  fielding,  sustainment,  and  upgrade  of  multifunction  RF  systems.  This 
section  summarizes  some  of  the  acquisition  approaches  that  were  discussed  and  how  they  might  impact 
the  InTop  program  and  future  development  efforts. 


6.1  Observations  and  Consensus 

Though  not  intended  to  be  exhaustive,  this  section  describes  some  of  the  observations  and  positions 
that  emerged  from  the  InTop  Open  Architecture  Study  around  which  there  was  broad,  if  not  unanimous, 
consensus. 

Open  Architecture  —  An  open  architecture  is  expected  to  be  one  that  has  a  stable  and  well-defined 
functional,  mechanical,  software,  and/or  physical  partitioning,  with  open  interfaces  defined  at  all  key 
partition  boundaries.  Open  interfaces  are  those  that  are  defined  using  widely  supported,  consensus-based 
standards  that  are  published  and  maintained  by  a  recognized  industry  or  government  standards 
organization  and  are  free  from  proprietary,  licensing,  and  royalty  constraints.  Where  practical  and 
compliant  with  present  and  foreseeable  system  requirements,  it  is  preferable  to  adopt  pre-existing  open 
industry  standards  that  have  proven  themselves  in  the  military  or  commercial  marketplace  and  that  have 
an  established  base  of  available  off-the-shelf  products.  In  cases  for  which  such  an  existing  open  industry 
standard  does  not  exist,  it  may  be  necessary  to  define  a  new  standard  for  the  InTop  program  or  other 
future  Navy  open  architecture  acquisition  programs.  In  these  cases,  the  interface  should  be  defined  such 
that  the  “widely  supported”  and  “consensus-based”  criteria  are  expected  results  to  be  developed  over 
time,  while  the  “partitioned  architecture”  and  “open  data  package”  criteria  apply  immediately. 

OA  Components  (SRU  and  SRA)  —  A  Ship  Replaceable  Unit  was  defined  for  the  purposes  of  this 
study  to  be  the  component  of  a  system  architecture  whose  functional,  electrical,  and  physical  interfaces 
are  open  in  accordance  with  the  OA  definition  given  above.  SRUs  represent  the  principal  partitioning 
elements  of  a  system  architecture.  It  is  assumed  that  the  Navy  is  the  ultimate  authority  for  approving  the 
functionality  and  key  performance  parameters  of  the  SRUs,  as  well  as  the  interface  standards  to  which 
they  must  comply.  A  Shop  Replaceable  Assembly  is  a  modular  assembly  within  an  SRU  that  is 
implemented  in  a  manner  that  facilitates  its  removal  and  replacement  for  repair  and  maintenance  reasons 
and  generally  not  deemed  to  have  critical  open  interfaces.  In  instances,  however,  where  an  SRA  as  a 
component  may  be  subject  to  future  support  or  technology  upgrades,  the  interfaces  should  be  considered 
open  and  developed  as  such. 

Common  Nomenclature  for  Architectural  Building  Blocks  —  A  standard  nomenclature  and 
diagramming  construct  allows  system  functions  to  be  shown  as  building  blocks  within  the  system 
architecture  at  a  level  of  abstraction  that  is  largely  independent  of  how  the  internal  functions  are 
implemented  or  on  what  technologies  they  rely.  The  particulars  of  the  nomenclature  are  not  critical, 
provided  that  the  nomenclature  adequately  documents  the  functions  provided  by  each  element  and 
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provides  descriptions  of  its  inputs,  outputs,  control,  and  status.  What  is  important  is  that  all  parties 
involved  (Navy  and  industry)  have  a  common  language  for  describing  architectures  that  they  propose  or 
endorse. 

While  the  InTop  Open  Architecture  Study  participants  came  to  recognize  the  importance  of  having 
such  a  common  nomenclature,  time  did  not  permit  the  establishment  of  a  standard.  This  is  evident  in 
Section  4  in  the  generic  architecture  descriptions  developed  by  the  four  subgroups. 

Two  comparable  nomenclatures/diagramming  constructs  were  considered  during  the  study.  The  DSP 
study  group  investigated  one  derived  from  the  Vita  Radio  Transport  standard.  The  VRT  protocol  is  an 
emerging  standard  for  Software  Definable  RF  (SDR)  applications.  It  was  developed  to  provide 
interoperability  between  a  diversity  of  SDR  components  by  defining  a  transport  protocol  to  convey 
digitized  signal  data  and  receiver  settings.  A  dataflow  key  is  shown  in  Fig.  6.1-1  and  an  example  building 
block  definition  is  provided  in  Fig.  6.1-2. 

A  second  nomenclature/diagramming  construct  was  devised  and  introduced  by  the  RF/IF  study 
group  as  shown  in  Section  4.2,  and  because  of  its  relative  simplicity,  was  used  by  the  other  three 
subgroups  to  some  degree,  although  adoption  of  a  standard  would  be  helpful  for  future  efforts. 


Gigabit  Ethernet  Control/Status  Interface 

Synchronization  between  modules  is  provided  by 
distributing  1  PPS  and  Reference  signal  (10  MHz) 

Signal  flow  indicator  for  analog  signal  data 


Signal  flow  indicator  for  digital  signal  data. 
Example:  parallel  ADC  data 

Signal  flow  indicator  for  packetized  digital  signal 
data.  Implies  data  is  time  stamped  and  is  sent 
over  serial  link  (10  GE,  SFPD,  HT...)  using  a 
common  data  transport  such  as  VITA  Radio 
Transport  (VRT). 


□ 


Process  Identification  number  (PID).  Unique  number 
to  reference  each  component  in  a  family  of  systems. 

Process  indicator.  Process  is  capable  of 
sending  out  context  (status)  packets. 


Process 

Analog  or  Digital 


Example  Process  symbol 
that  indicates  the  process  is 
capable  of  receiving 
commands  and  giving  status 


Example  Process  symbol 
that  indicates  that  the 
process  is  capable  of 
receiving  commands  and 
giving  status  and  sending 
out  streaming  data  packets 


Process  indicator.  Process  is  capable  of 
receiving  command  packets. 

Process  indicator.  Process  is  capable  of 
sending  out  signal  data  packets. 

Process  indicator.  Process  is  capable  of 
receiving  signal  data  packets 


Process 

Digital  Input 


Example  Process  symbol 
that  indicates  that  the 
process  is  capable  of 
receiving  commands  and 
giving  status  and  receiving 
streaming  data  packets 


Fig.  6.1-1  —  Modified  VRT  dataflow  key 
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-  Filter  selection 

•  If  a  number  of  coefficients  are  stored 
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Status  output 
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Packetized  data  input 

-  Digitized  IF 
Processor  function 

-  Execute  control  inputs 

-  Produce  status  outputs 

-  DDC  and  decimation  processing 

-  Packetize  and  serialize  data  output 

Packetized  data  output 

-  Complex  baseband  data 


Fig.  6.1-2  —  Sample  building  block  description  using  VRT  nomenclature 


No  “One  Size  Fits  All”  Architecture  —  It  was  recognized  early  on  that  the  optimal  choice  of 
architectural  partitioning  can  be  a  strong  function  of  system  requirements,  particularly  the  frequency 
regime  in  which  the  system  must  operate.  A  multifunction  RF  system  designed  to  operate  in  the 
VHF/UHF  bands  could  consider  direct  digitization,  for  example,  while  such  an  approach  would  not  be 
viable  in  the  Ka/Q-band  with  today’s  technology.  Similarly,  the  grid  size  required  for  millimeter-band 
arrays  tends  to  dictate  higher  levels  of  functional  integration  into  front-end  electronic  SRUs  simply  to 
avoid  an  untenable  interconnect  issue  at  an  intermediate  interface  boundary.  An  L/S-band  array  would  not 
necessarily  be  held  to  such  a  constraint.  As  the  InTop  program  will  be  looking  at  reducing  total  topside 
aperture  quantities  by  employing  apertures  that  are  federated  by  frequency  band  rather  than  by  function,  it 
is  much  more  practical  to  realize  this  architectural  optimization  for  each  multifunction  system. 

6.2  Ongoing  Considerations 

This  section  identifies  a  few  points  that  require  further  consideration  in  the  process  of  creating  a 
modular,  open,  scalable  architecture.  Unlike  the  observations  described  in  the  previous  section  for  which 
there  was  general  consensus  among  InTop  OA  Study  participants,  the  topics  identified  in  this  section 
remain  under  discussion  as  architectures  are  further  considered  and  evaluated.  As  with  the  previous 
section,  this  list  is  not  intended  to  be  exhaustive. 
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The  Importance  of  Component/SRU  Partitioning  —  Partitioning  and  interface  definition  are  two 
of  the  main  aspects  of  creating  a  modular,  open,  scalable  architecture.  Of  these,  partitioning  tends  to  have 
a  much  greater  impact  on  the  potential  to  realize  the  long-term  benefits  of  such  an  architecture.  Too  fine  a 
partitioning  granularity,  and  the  system  solution  space  becomes  over-constrained,  stifling  innovation, 
impeding  technology  advancements,  and  forcing  the  added  costs  and  performance  impacts  of  complying 
with  too  many  interface  requirements.  Too  coarse,  and  the  system  loses  some  of  its  extensibility  benefits. 
It  becomes  less  accepting  of  discrete  technology  upgrade  opportunities  —  it  becomes  more  stove-piped 
and  less  “open.”  In  short,  the  trade-off  to  be  considered  with  SRU  granularity  is  between  innovation  and 
standardization.  As  with  virtually  all  trade-offs,  affordability  (both  acquisition  and  life-cycle  costs)  will 
also  be  an  important  variable  to  consider. 

For  a  given  architectural  partitioning,  there  may  be  several  interface  standards  that  are  acceptable. 
Provided  the  selected  interface  standard  meets  the  definition  of  “open”  and  accommodates  the  required 
system  capabilities  and  capacities,  the  specific  choice  of  standard  is  less  critical. 

Architectures  Should  be  Stable,  Though  Not  Necessarily  Static  —  The  rate  of  evolution  of 
interface  standards  and  system  partitioning  is  an  important  parameter  in  system  architecture  trade-off 
analysis.  To  realize  many  of  the  benefits  of  modular,  open,  scalable  architectures,  the  partitioning  and 
interface  decisions  must  be  stable  over  some  reasonable  period  of  time.  This  provides  industry  time  to 
develop  new  and  improved  products  and  subsystems  that  conform  to  interface  specifications  that  remain 
fixed.  To  realize  the  benefits  of  contractor  Independent  Research  and  Development  (IRAD)  investments 
(and  innovation),  contractors  need  to  be  confident  that  the  interfaces  with  the  system  hardware  and 
software  components  (SRU/CSCI)  that  they  are  developing  will  not  change  before  they  are  able  to 
compete  for  capability  upgrades. 

At  the  same  time,  it  is  important  to  note  that  standards  and  requirements  do  evolve  with  time.  It  is 
difficult  to  project  the  extent  to  which  a  given  standard,  or  its  relevance  to  a  multifunction  system,  will 
endure.  The  maturation  of  new  technologies  can  yield  enough  of  a  cost  or  capability  improvement  to 
justify  the  alteration  of  a  system  architecture  and  related  interfaces.  An  example  of  this  can  be  seen  in  the 
recent  emergence  of  highly  integrated  RF  System-on-a-Chip  technologies  that  will  soon  enable  fully 
digital  beamforming  integrated  directly  into  the  array  SRU.  The  evaluation  of  architecture  candidates  for 
a  forward-looking  program  like  Integrated  Topside  will  need  to  anticipate  how  soon  these  technologies 
will  be  ready  for  advanced  development,  and  favor  architectural  constructs  that  allow  for  their  insertion. 

Back-fit  Compatibility  vs.  Unconstrained  System  Optimization  —  Ideally,  the  modular,  open, 
scalable,  multifunction  RF  systems  that  emerge  from  the  Integrated  Topside  program  will  not  only 
represent  the  best  match  of  technology  and  capability  for  future  platforms,  but  will  also  be  easily  adapted 
to  back-fit  into  the  legacy  fleet.  In  reality,  however,  this  may  prove  to  be  easier  said  than  done.  How  do 
you  define  open  architecture  systems  that  are  backward  compatible  with  decades-old  stove-piped  systems 
without  unduly  constraining  system  architects  and  design  engineers  as  they  explore  ways  to  leverage  new 
technologies  to  fit  the  performance,  capacity,  and  flexibility  demands  of  new  platforms?  Here,  the  Navy 
will  need  to  clearly  articulate  back-fit  vs.  forward-fit  requirements  and  their  relative  priorities  as  they 
work  with  industry  in  defining  new  multifunction  Advanced  Development  Models. 

Permitting  the  Integration  of  Adjacent  Components/SRUs  —  Under  what  conditions  can  a  pre- 
established  standard  interface  be  consumed  by  a  component?  Said  differently,  under  what  conditions  can 
two  adjacent  pre-established  components  be  combined  into  one?  One  of  the  features  of  a  modular,  open, 
scalable  architecture  is  the  relative  ease  with  which  it  can  be  upgraded  as  new  techniques  and 
technologies  come  on  line.  When  tech  insertion  upgrades  are  considered,  there  may  be  justifiable  reasons 
to  allow  a  single,  more  highly  integrated  component  to  replace  two  existing  components,  essentially 
eliminating  the  open,  standard  interface  that  was  defined  between  them,  while  retaining  the  interfaces  at 
the  outer  boundaries  of  the  two  original  components. 
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It  is  not  hard  to  see  possible  future  cases  in  which  emerging  integrated  circuit  technologies  allow  the 
functions  of  multiple  components  to  be  so  tightly  integrated  that  having  to  conform  to  pre-existing 
interface  standards  would  defeat  the  significant  cost,  size,  weight,  and  power  benefits  of  the  new 
technology.  This  technology  will  undoubtedly  evolve  to  the  point  where  it  becomes  practical  to  integrate 
RF/IF  conversion  and  digitization  directly  into  the  array  electronics  that  are  co-located  with  the  aperture. 
If  the  benefits  are  significant  enough  in  cases  like  this,  consolidation  is  clearly  warranted.  It  should  be 
noted,  however,  that  there  is  a  degree  of  modularity  that  is  lost  when  components  are  combined  and  an 
interface  is  consumed.  A  cost-benefit  assessment  (business  decision)  should  be  conducted  before 
combining  two  components  into  one  to  ensure  that  the  size,  weight,  power,  cost,  and  performance 
advantages  outweigh  the  incremental  loss  in  modularity. 


6.3  Acquisition 

In  addition  to  being  a  technical  strategy  for  developing  systems  around  widely  supported,  consensus- 
based  standards,  open  architecture  is  also  a  business  strategy.  If  implemented  effectively,  OA 
significantly  increases  innovation  and  competition,  expedites  technology  insertion,  expands  opportunities 
for  hardware  and  software  reuse,  and  reduces  maintenance  constraints.  For  the  Department  of  Defense 
and  the  industry  base  that  supports  it,  however,  OA  is  not  always  business  as  usual.  It  requires  some 
fundamental  shifts  in  government  acquisition  approaches  and  in  the  strategic  decision-making  processes 
within  industry,  including  IRAD  investments,  product  development  and  marketing  approaches,  partnering 
strategies,  and  intellectual  property  management. 

The  Integrated  Topside  Oversight  Board  identified  some  of  these  issues,  discussed  how  they  affect 
the  development  of  multifunction  RF  systems,  and  explored  ways  to  tailor  the  acquisition  and  business 
models  to  best  achieve  the  objectives  of  the  InTop  program.  As  might  be  expected,  there  were  not  clear- 
cut  answers  to  all  questions  that  arose  on  this  topic.  Even  so,  there  is  value  in  identifying  the  questions  so 
that  they  can  be  given  thoughtful  consideration  and  be  resolved  over  time. 

What  are  the  Navy’s  objectives  for  using  open  architecture  principles  and  a  modular  open 
systems  approach  (MOSA)  in  the  acquisition  and  development  of  multifunction  RF  systems? 

•  Enable  increased  competition  —  By  defining  stable,  open  interface  standards  in  the  architecture 
and  using  an  open  business  model  in  the  acquisition  process,  a  much  broader  base  of  products  and 
suppliers  is  available  to  address  the  Navy’s  needs.  This  mitigates  the  risk  of  a  single  source  of 
supply  over  the  life  of  a  system.  It  may  also  have  the  collateral  benefit  of  increasing  collaboration 
among  contractors  wherein  each  brings  their  respective  competitive  discriminators  to  improve 
their  probability  of  contract  award. 

•  Leverage  commercial  investment  and  commercial  innovation  —  Stable,  open  interface 
definitions  expand  the  market  for  components  that  conform  to  those  standards.  They  encourage 
industry  to  invest  in  applicable  products.  To  the  extent  that  the  interfaces  are  widely  used  in  the 
commercial  sector,  the  Navy  takes  advantage  of  innovations  that  are  motivated  by  those  larger, 
more  lucrative  markets.  A  side  benefit  is  the  cost  advantage  associated  with  larger  supplier  and 
customer  bases  for  these  COTS  products. 

•  Enhance  access  to  cutting-edge  technologies  —  The  inherent  extensibility  of  open  systems 
creates  opportunities  for  technology  insertions  with  relative  ease.  This  also  mitigates  the  risks 
associated  with  technology  obsolescence. 

•  Enhance  commonality  and  reuse  across  platforms,  programs,  and  life-cycle  support  — 

Common  architectures  enable  common  components.  This  enhances  life-cycle  supportability  and 
reduces  maintenance  costs. 
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•  Enhance  system  hardware  and  software  commonality  across  multiple  platforms  and 
missions  —  A  modular  and  scalable  architecture  facilitates  the  tailoring  of  InTop  systems 
through  the  selection  and  integration  of  one  or  more  appropriate  modules  to  satisfy  particular 
platform  size  and  mission. 

How  well-defined  and  detailed  should  the  architecture  be  in  future  development  task  orders  or 
solicitations?  In  initiating  System  Development,  there  are  two  approaches  for  selecting  a  MOSA-based 
architecture.  The  first  is  characterized  by  a  solicitation  that  fully  defines  the  system  architecture  (i.e., 
complete  SRU  and  interface  definitions)  as  a  fundamental  requirement.  The  second  involves  the 
solicitation  establishing  MOSA  guidelines  and  evaluation  criteria  and  asking  contractors  to  propose  their 
own  architectures.  In  the  latter  case,  the  source  selection  process  essentially  selects  the  architecture  along 
with  the  winning  contractor.  The  more  “open”  of  these  two  acquisition  models  is  the  former,  where  all 
bidders  propose  solutions  against  a  well-defined  requirement,  and  source  selection  comparisons  can  be 
made  on  a  more  objective,  “apples-to-apples”  basis.  A  strategy  that  could  realize  the  benefits  of  both 
approaches  is  a  two-step  acquisition.  In  a  first  solicitation  (or  task  order),  contractors  are  asked  to  propose 
an  architecture  and  an  associated  rationale.  After  selecting  a  preferred  architecture  in  this  first  step,  a 
second  solicitation  (or  task  order)  is  issued  to  the  contractor  community  to  bid  a  system  solution  that 
conforms  to  this  architecture. 


How  is  open  architecture  evaluated  during  a  source  selection  and  development?  How  is  MOSA 
implementation  progress  monitored  and  assessed?  How  are  conformance  of  the  SRU/CSCI  “as 
built”  specifications  and  interfaces  to  be  validated  and/or  certified?  —  Regardless  of  the  approach 
used  to  define  a  MOSA-based  architecture,  it  is  important  that  a  clearly  defined  set  of  MOSA  evaluation 
factors/criteria  be  developed  and  communicated  to  the  contractor  community  in  the  solicitation.  These 
criteria  serve  to  reinforce  the  importance  of  the  application  of  OA  principles  and  adherence  to  MOSA, 
and  focus  all  bidders  to  adjust  their  systems  engineering  processes  accordingly.  The  Naval  Open 
Architecture  Contract  Guidebook  10  provides  more  specific  recommended  requirements  and  evaluation 
factors. 


Who  should  be  the  prototype  system  integrator?  What  is  their  role?  What  role  does  the  Navy 
play  in  initial  make/buy  decisions?  There  was  much  debate  during  the  study  on  this  topic,  and  less  than 
full  consensus.  Given  the  MOSA  objective  for  increased  competition,  if  System  Integrators  (Sis)  are 
permitted  to  compete  for  the  development  of  System  Elements,  there  is  a  valid  argument  that  they  should 
not  derive  any  competitive  advantage  relative  to  other  developers  simply  by  virtue  of  their  position  as  an 
SI.  Examples  of  competitive  advantages  include  (a)  source  selection  of  System  Element  Developers 
(SEDs)  when  the  SI  (or  related  coiporate  entity)  is  competing  as  an  SED,  (b)  incorporation  of  proprietary 
techniques  into  the  Systems  Integration  process  (i.e.,  things  that  would  create  a  bander  to  entry  for  any 
other  prospective  Sis  or  SEDs),  and  (c)  forcing  subordinate  SEDs  to  convey  intellectual  property  data 
rights  to  them  as  a  condition  of  their  selection.  The  concepts  of  “firewalling”  the  SI  team  from  the  SED 
segment  of  the  company  to  allow  them  to  compete,  and/or  having  the  Navy  conduct  the  source  selection 
were  also  discussed  but  without  conclusion. 


10  Naval  Open  Architecture  Contract  Guidebook,  Version  1.1,  prepared  by  Program  Executive  Officer,  Integrated 
Warfare  Systems,  25  October  2007,  available  at  https://acquisition.navy.mil/rda/content/view/full/5528. 
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What  is  the  impact  of  open  architecture  on  intellectual  property  and  data  rights?  If  done 
correctly,  moving  from  proprietary,  stove -piped  systems  to  open  systems  architectures  does  not  diminish 
the  value  of  intellectual  property  as  a  competitive  discriminator.  At  most,  it  simply  ensures  that  the 
contractors’  intellectual  property  is  focused  on  capabilities  and  performance  within  an  SRU  rather  than  on 
the  interfaces  between  SRUs.  An  open  system  requires  only  that  the  interface  standards  be  open  (and  thus 
non-proprietary).  The  innovation  resides  within  the  SRUs. 

6.4  InTop  Acquisition  Considerations 

Acquisition  approaches  for  InTop  must  consider  technology  evolution,  managed  risk,  prototype  and 
engineering  demonstrations,  and  transition  strategies.  They  must  also  foster  competition  throughout  the 
system  life  cycle  while  leveraging  the  mutual  understanding  established  between  the  Navy  and  industry 
during  this  initial  system  study  phase. 

The  InTop  program  considered  a  number  of  acquisition  approaches  to  implement  OA  principles  and 
address  the  InTop  vision.  These  include  parallel/dual-source  development  up  to  and  including  acquisition; 
use  of  a  large  scale  integrator  as  a  prime  contractor  for  InTop  and  related  topside  systems;  dual-source 
through  design  and/or  ADM,  with  competition  for  System  Design  and  Development  (SDD);  and  parallel 
architecture  studies  leading  to  a  competition  for  ADM  based  on  the  recommendations  from  those  studies, 
and  SDD  based  on  the  then-proven  ADM  architecture.  Note  that  these  approaches  are  not  necessarily 
mutually  exclusive  and  that  the  InTop  program  must  weigh  the  benefits  of  each  as  it  proceeds  to 
Advanced  Development  and  transitions  to  SDD  and  production. 

The  InTop  program  has  initially  held  a  competition  for  award  of  an  Indefinite  Delivery/Indefmite 
Quantity  (IDIQ)  contract  for  follow-on  InTop  tasks.  Eighteen  contractors  were  determined  to  be  qualified 
in  one  or  more  categories  —  System  Developer;  Niche  Developer;  System  Integrator  —  and  were 
awarded  an  IDIQ  contract. 

Initial  task  orders  to  be  awarded  on  the  IDIQ  contract  include  multiple  system  studies  which  will 
transition  to  one  or  more  ADM  design  efforts  based  on  the  requirements  derived  from  the  studies.  These 
tasks  will  then  transition  to  ADM  system  fabrication,  integration,  and  test.  The  resulting  architecture  may 
be  recompeted  for  SDD.  Niche  Developers  may  participate  as  appropriate. 

6.5  Benefits,  Challenges,  and  Risks 

The  benefits  of  an  OA/MOSA  implementation  of  InTop  are  potentially  revolutionary  for  the  Navy 
fleet,  but  require  high-level  vision  and  leadership  across  its  organizations.  Clear  and  accurate  life-cycle 
support  analyses  are  necessary  and  must  be  updated  continuously  through  the  design  and  development 
cycle.  Further  operational  analysis  must  be  performed  to  ensure  the  viability  of  achieving  the  required 
level  of  multifunctional  performance  from  common  aperture,  RF,  and  signal  processing  resources. 
Applying  these  analyses  to  the  requirements  flow-down  process  and  to  architectural  assessments  on  the 
InTop  program  ensures  that  future  capability  needs  of  the  fleet  are  addressed  by  the  systems  defined  and 
developed  under  InTop. 

The  short-term  and  long-term  benefits  of  OA-based  system  development  are  many,  and  have  been 
cited  throughout  this  report.  Business/acquisition  benefits  include  the  following: 

•  Enabling  increased  industry  competition  and/or  collaboration; 

•  Leveraging  commercial  investment  and  commercial  innovation; 

•  Realizing  cost  advantages  of  larger  supplier  and  customer  bases; 

•  Enhancing  access  to  cutting-edge  technologies  and  products  from  multiple  suppliers; 
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•  Mitigating  the  risks  associated  with  technology  obsolescence; 

•  Mitigating  the  risk  of  a  single  source  of  supply  over  the  life  of  a  system; 

•  Enhancing  commonality  and  reuse  of  components  among  systems; 

•  Enhancing  life-cycle  supportability,  reducing  maintenance  costs. 

Operational  performance  benefits  include  these: 

•  The  ability  to  adapt  to  evolving  requirements  and  threats; 

•  Accelerating  the  transition  from  science  and  technology  into  acquisition  and  deployment  (making 
technology  refresh  an  asset,  not  a  liability); 

•  Ensuring  that  the  system  will  be  interoperable  with  all  the  systems  with  which  it  must  interface, 
without  major  modification  of  existing  components; 

•  Improving  the  extensibility  for  meeting  new  requirements  and  for  introducing  new  capabilities. 


Along  with  these  benefits  come  challenges,  risks,  and  implications  that  may  affect  both  the 
Government  and  industry  on  several  fronts. 

•  “Open”  information  —  interfaces  and  specifications  —  developed  by  the  prime  during  SDD  must 
be  confirmed  to  be  sufficient  and  accurate  before  initiating  component  procurement  from  an 
alternate  source  and  subsequent  integration  into  a  fielded  system. 

•  The  price  for  lower  total  life-cycle  costs  could  be  higher  initial  acquisition  cost. 

•  Commercial  product  lifetimes  are  generally  much  shorter  than  that  of  the  weapon  system, 
creating  challenges  to  logistical  support  functions. 

•  To  maintain  a  healthy  supplier  base,  the  contract  community  (large  defense  contractors, 
commercial  product  houses,  and  niche  system  element  developers)  must  see  a  sustainable,  long¬ 
term  business  case.  The  Navy  must  provide  protection  of  contractor  intellectual  property  within 
the  open  components  (SRU/CSCI),  even  as  it  demands  compliance  to  open,  non-proprietary 
interfaces. 

•  Standards  selection  can  be  risky  and  problematic.  It  will  require  that  the  Government  have  more 
knowledge  of  the  current  state  of  the  art  and  the  marketplace. 

•  Interface  standards  evolve  with  time.  It  is  difficult  to  project  the  extent  to  which  a  given  standard 
will  endure.  It  is  also  challenging  to  determine  when  to  change  from  one  standard  to  the  next. 

•  Standards-based  architectures  tend  to  change  the  focus  of  systems  engineering  from  design  to 
integration.  The  challenge  is  to  achieve  performance  requirements  without  detailed  control  over 
the  component  design  specification. 


The  Navy  needs  to  weigh  these  benefits,  challenges,  risks,  and  implications  to  prove  to  itself  that 
implementing  its  concept  for  a  multifunction  RF  integrated  topside  incorporating  OA  principles  is  cost- 
effective  and  mission-compliant  over  the  long  term.  To  do  this  will  require  accurate  and  credible  cost 
models,  a  sustainable  technology  and  engineering  base,  and  a  willingness  by  the  Navy  to  alter  its  own 
cultural  and  acquisition  processes. 
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7.  CONCLUSION  AND  FUTURE  WORK 

Much  of  the  benefit  of  this  InTop  Open  Architecture  Study  was  the  introduction  of  the  Navy  and 
industry  participants  to  open  architecture  concepts,  the  establishment  of  consensus  in  developing  notional 
system  architectures  and  interfaces,  and  an  understanding  of  the  value  of  OA  to  the  InTop  program  and 
the  application  of  a  modular  open  systems  approach  to  InTop  development. 

The  primary  technical  result  of  this  OA  study  was  to  identify  and  define  generic  functional 
components  (SRUs/CSCIs)  and  their  related  interfaces  that  can  be  expected  to  be  non-proprietary  and 
relevant  to  most  InTop  systems.  Subsequent  development  efforts  will  focus  system  architectures  on  these 
building  blocks,  and  develop  open  interfaces  as  the  core  of  a  modular  open  systems  approach  for  InTop. 

The  primary  program  benefit  of  this  OA  study  was  a  mutual  recognition  by  InTop  participants  of 
recent  Navy  difficulties  with  updating  and  integrating  both  legacy  and  new  systems  encumbered  with 
proprietary  hardware  and  software.  Future  InTop  development  must,  therefore,  incoiporate  the  principles 
of  open  architecture  to  effectively  adapt  to  existing  communications  and  sensor  systems,  new  platform 
operational  and  design  requirements,  and  associated  new  and  legacy  combat  control  systems. 

The  primary  business  impact  on  industry  of  adopting  an  OA  approach  involves  intellectual  property 
and  broader  open  competition.  While  it  is  recommended  that  new  OA  systems  be  developed,  integrated, 
and  delivered  by  a  single  prime  contractor  responsible  for  all  aspects  of  cost,  schedule,  and  performance, 
IP  should  be  limited  to  well-defined  SRUs  and  CSCIs  (and  where  applicable,  SRAs).  In  turn,  however, 
the  competition  for  future  enhancements  should  be  open  to  all  and  not  restricted  to  the  original  prime;  this 
widening  and  leveling  of  the  “playing  field”  increases  new  business  opportunities  for  all  without 
restricting  companies  to  their  past  legacy  systems.  Additionally,  OA  increases  the  prime  contractor’s 
make-buy  opportunities  and  its  ability  to  deliver  a  better  product  at  lower  cost  by  providing  greater 
incentive  for  outside/niche  development  of  OA  elements.  The  OA  modular  approach  also  increases  the 
domestic  and  foreign  market  by  providing  additional  flexibility  to  support  new  platforms  with  varying 
configurations  and  operational  requirements. 

Many  program,  technical,  and  business  questions  remain,  however,  and  further  work  is  required  to 
address  such  issues  as  the  following: 

•  Intellectual  property  and  proprietary  requirements 

•  Navy  versus  industry  architecture  definition,  development,  and  configuration  control 

•  System  Integrator  responsibilities 

•  Balancing  and  evaluating  the  likely  higher  initial  cost  of  acquisition  versus  the  expected  future 
savings  in  out-year  support  and  life-cycle  cost 

•  Possible  increase  in  long-term  costs  caused  by  short  lifetimes  of  COTS  modules.  While  COTS 
module  procurement  can  be  expected  to  lower  initial  cost  by  leveraging  the  civilian  market  and 
standard  interfaces,  COTS  product  lifetimes  are  generally  much  shorter  than  the  host  weapons 
system.  Such  short-term  obsolescence  may  increase  the  costs  of  long-term  support. 

•  Impact  of  future  technology  development  on  a  particular  standardized  architecture;  e.g.,  the 
incorporation  of  RF/IF  into  the  aperture  modules. 

•  Standard  interfaces  versus  system-unique  (but  open/Govemment-owned)  interfaces 

•  Navy/third  party  validation  of  component  specifications  and  interfaces.  Recent  experience  on  the 
MFEW  program  has  shown  that  a  simple  error  in  interface  data  or  insufficient  specification 
information  may  significantly  impact  (and  may  even  negate)  the  Navy’s  ability  to  integrate  new 
subassemblies. 
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Time  and  scope  did  not  allow  investigation  of  these  issues  during  this  study.  They  will  be  addressed 
as  the  InTop  program  progresses  through  Advanced  Development  and  transition  to  SDD  and  production. 

In  closing,  we  have  presented  a  summary  of  the  deliberations  and  initial  findings  of  the  Integrated 
Topside  Open  Architecture  Study.  We  have  provided  guidance  on  how  an  open,  multifunction  RF  system 
may  be  partitioned  into  a  reasonable  set  of  constituent  parts.  It  is  our  hope  that  this  report  offers  insight 
into  the  benefits  of  open  architecture  system  development,  and  a  way  forward  to  meet  the  challenges 
presented  by  this  approach. 
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8.  ACRONYMS 


A/D 

Analog-to-Digital 

AC 

Alternating  Current 

ADC 

Analog-to-Digital  Converter 

ADM 

Advanced  Development  Model 

AEHF 

Advanced  Extremely  High  Frequency 

AMF 

Airborne  and  Maritime-Fixed 

AMRFC 

Advanced  Multifunction  Radio  Frequency  Concept 

ANSI 

American  National  Standards  Institute 

AoA 

Angle  of  Arrival 

ASIC 

Application-Specific  Integrated  Circuit 

BIT 

Built-In-Test 

BSC 

Beam  Steering  Computer 

CBSP 

Commercial  Broadband  Satellite  Program 

CDF 

Common  Data  Link 

CDF-N 

Common  Data  Link  -  Navy 

CEC 

Cooperative  Engagement  Capability 

CFC 

Communications  Function  Controller 

Cl 

Combat  Identification 

CIC 

Combat  Information  Center 

CIWS 

Close-In  Weapon  System 

Clks 

Clocks 

COMSEC 

Communications  Security 

CONOPS 

Concept  of  Operations 

COP 

Common  Operating  Picture 

COTS 

Commercial  Off-The-Shelf 

CPE 

Configurable  Processing  Element 

CS 

Combat  System 

CSCI 

Computer  Software  Configuration  Item 

D/A 

Digital-to-Analog 

DAC 

Digital-to-Analog  Converter 

DC 

Direct  Current 

DCLS 

Direct  Current  Level  Shift 

DMA 

Direct  Memory  Access 

DP 

Data  Processing 

DRFM 

Digital  RF  Memory 

DSP 

Digital  Signal  Processor 

DTV 

Direct  TV 

EA 

Electronic  Attack 

EBEM 

Enhanced  Bandwidth  Efficient  Modem 

EFC 

EW  Function  Controller 

EICS 

External  Interface  Controller  Subsystem 

EIRP 

Effective  Isotropically  Radiated  Power 

EMC 

Electromagnetic  Compatibility 

EMCON 

Emission  Control 

EMI 

Electromagnetic  Interference 

ES 

Electronic  Support 

ESM 

Electronic  Support  Measures 

EW 

Electronic  Warfare 
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FEC 

Forward  Error  Correction 

FIFO 

First  In,  First  Out 

FIR 

Finite  Impulse  Response 

FOV 

Field  Of  View 

FPGA 

Field-Programmable  Gate  Array 

FSS 

Frequency  Selective  Surface 

G/T 

Gain/Temperature  (degrees  Kelvin) 

Gbps 

Gigabits  Per  Second 

GBS 

Global  Broadcast  System 

GE 

Gigabit  Ethernet 

GPPE 

General-Purpose  Processing  Element 

GUI 

Graphical  User  Interface 

HGHS 

High  Gain  High  Sensitivity 

HPA 

High  Power  Amplifier 

HPOI 

High  Probability  of  Intercept 

HV  Power 

High  Voltage  Power 

I&T 

Integration  and  Test 

IB 

InfiniBand 

ICD 

Interface  Control  Document 

IDIQ 

Indefinite  Delivery/Indefinite  Quantity 

IER 

Information  Exchange  Requirements 

IETF 

Internet  Engineering  Task  Force 

IF 

Intermediate  Frequency 

IMU 

Inertial  Measurement  Unit 

INP 

Innovative  Naval  Prototype 

INS 

Inertial  Navigation  System 

InTop 

Integrated  Topside 

10 

Information  Operations 

IP 

Intellectual  Property 

IPv6 

Internet  Protocol  version  6 

IR 

Infrared 

IRAD 

Independent  Research  and  Development 

IRIG-B 

Inter  Range  Instrumentation  Group 

ISR 

Intelligence,  Surveillance,  Reconnaissance 

ITOB 

Integrated  Topside  Oversight  Board 

JCTN 

Joint  Composite  Tracking  Network 

JTRS 

Joint  Tactical  Radio  System 

FAMPS 

Fight  Airborne  Multi-Purpose  System 

FDR 

Fow  Data  Rate 

ENA 

Fow  Noise  Amplifier 

FO 

Focal  Oscillator 

EOS 

Fine  Of  Sight 

FRM 

Focal  Resource  Manager 

MDR 

Medium  Data  Rate 

MFEW 

Multifunction  Electronic  Warfare 

MICD 

Mechanical  Interface  Control  Document 

MIDS 

Multifunction  Information  Distribution  System 

MMIC 

Monolithic  Microwave  Integrated  Circuit 

MOSA 

Modular  Open  Systems  Approach 

MTBF 

Mean  Time  Between  Failures 

NAY 

Navigation 
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NAVSEA 

Naval  Sea  Systems  Command 

NAVSSI 

Navigation  Sensor  System  Interface 

NF 

Noise  Figure 

NFS 

Network  File  System 

NMT 

Navy  Multiband  Terminal 

NRF 

Naval  Research  Laboratory 

NSWCDD 

Naval  Surface  Warfare  Center,  Dahlgren  Division 

NTP 

Network  Time  Protocol 

NUWC 

Naval  Undersea  Warfare  Center,  Newport 

OA 

Open  Architecture 

ONR 

Office  of  Naval  Research 

PA 

Power  Amplifier 

PC 

Personal  Computer 

PDF 

Precision  Direction  Finding 

PPS 

Pulse  Per  Second 

PRI 

Pulse  Repetition  Interval 

PTP 

Precision  Time  Protocol 

RAM 

Resource  Allocation  Manager 

RCS 

Radar  Cross  Section 

RDMA 

Remote  Direct  Memory  Access 

RF 

Radio  Frequency 

RFC 

Radar  Function  Controller 

RJ 

Rotary  Joint 

RMS 

Root  Mean  Square 

RT  Ctrl  Net  (RTCN) 

Real-Time  Control  Network 

Rx 

Receive 

SA 

Subaperture 

SA 

Situation  Awareness 

SATCOM 

Satellite  Communications 

SDD 

System  Design  and  Development 

SDR 

Software  Definable  RF 

SED 

System  Element  Developer 

SEI 

Specific  Emitter  Identification 

SEWIP 

Surface  EW  Improvement  Program 

SI 

System  Integrator 

SEE 

Side  Lobe  Level 

SPAWAR  SC 

Space  and  Naval  Warfare  Systems  Center 

SPPE 

Special-Purpose  Processing  Element 

SRA 

Shop  Replaceable/Repairable  Assembly 

SRU 

Ship  Replaceable  Unit 

SSH 

Secure  Shell 

SW 

Software 

SW 

Switch 

T/R 

Transmit/Receive 

TBD 

To  Be  Determined 

TCP 

Transmission  Control  Protocol 

TCP/IP 

Transmission  Control  Protocol/Internet  Protocol 

ToD 

Time  of  Day 

TRANSEC 

Transmission  Security 

Tx 

Transmit 

UDP 

User  Datagram  Protocol 
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UDP/IP 

User  Datagram  Protocol/Internet  Protocol 

UHF 

Ultra  High  Frequency 

VITA 

VME  International  Trade  Association 

VME 

VERSA  Module  Eurocard  (computer  architecture  std) 

VRT 

VITA  Radio  Transport 

VSWR 

Voltage  Standing  Wave  Ratio 

W/G 

Wave  Guide 

WGS 

Wideband  Gapfiller  Satellite 

XDR 

High  Data  Rate 
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